Hi,
I am Varun and I want to participate for GSOC this year. I have been looking at the project ideas on the Ideas Page. Well I wanted to work on the idea "digiKam MySQL / MariaDB Database support". It would be helpful if someone could guide me to as where to get the documentation related to the idea so I could get an early start and get familiar with the code. Regards, Varun _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Hi, What's your skill exactly ? Did you have any experience in database ? Best Gilles Caulier 2016-02-23 19:28 GMT+01:00 Varun Gupta <[hidden email]>:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Hi, Gills I looked at the prerequisites for the project and I am comfortable with them except for Qt. Qt I hope to learn soon. Well as for databases I am comfortable with both MYSQL and SQLITE. Regards, Varun On Wed, Feb 24, 2016 at 1:10 AM, Gilles Caulier <[hidden email]> wrote:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Varun, * Qt is important to understand all the code. The digiKam database, that is review and reorganized during Qt5 port is large and complex. I recommend to take a look into the code before to start all investigations, to check If you will be fine with the implementations. This is the first stage of this project : to be able to understand quickly the current code. There are 3 database types : 1/ Sqlite 2/ Local Mysql server (working as Sqlite with a dedicated server implemented in digiKam core) 3/ Remote Mysql server 1/ work very well and is stable. 2/ work but schema need big improvement and hack. 3/ need requirement of 2 plus new code to be compatible with concurrent access by multiple digiKam session at the same case (Photo agency use case) * The second stage of this project is to look in databases schemas, that i s also review and re-organize while Qt5 port. The digiKam database interface as a XML wrapper tho handle schemas, written in different sections of a big XML file : For each Database types, we have 3 database container : - Core (the big one for digiKam properties) - Thumbnails (to store wavelets thumbs of images) - Faces (to store faces finger prints for detection and recognition). In the database implementation, you will find sub sections dedicated for dedicated features. * The 3rd stage of this project is to review buzilla reports that i sorted for database and list all main problems to fix by priority order for Mysql types. * The last stage to complete this first pre-analyze of this project is to write a google doc to list all technical details listed below plus all your investigations, before to write the proposal for GSoC. I'm waiting questions now. Good luck Gilles Caulier 2016-02-24 2:38 GMT+01:00 Varun Gupta <[hidden email]>:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
I have started looking at the code from the given link [1] . I still have doubts what do you mean by the last stage , in the doc do i have to list all the main problems that need to be fixed for MYSQL types? https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/show/libs/database On Wed, Feb 24, 2016 at 11:58 AM, Gilles Caulier <[hidden email]> wrote:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
2016-02-24 21:42 GMT+01:00 Varun Gupta <[hidden email]>:
Exactly. Accordingly with Agile method, bugzilla is the reference to evolute and fix open source application. I already review and sort all entries in bugzilla (including duplicates) about MySql support. It will be not to hard to list the main dysfunctions about Mysql support depending of users contexts reported. Of course, there is an order to fix the problem due to interdépendances between tasks to patch the current implementation of database interface. Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Any feddback here. Did you checkout code and look in DB interface implementation ? Any questions ? Best Gilles Caulier 2016-02-24 22:07 GMT+01:00 Gilles Caulier <[hidden email]>:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
I have finished with reading the code in the folder collection and coredb from link [1]. I got familiar with the code but I guess there is lots of code to read , so it would be helpful if you could redirect me to the parts which are immediately essential so I get the understanding of the important parts and then go on with the rest of the code. Regards, varun On Sun, Feb 28, 2016 at 4:49 PM, Gilles Caulier <[hidden email]> wrote:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In core/libs/database, the README file give some description for each sub-directories : As i said previously, DK use 3 Databases (core, thumbs, faces), with 3 differents schemas. For these 3 databases, we have 3 backends : 1/ sqlite, 2/ local mysql server 3/ remote Mysql For the 2/, we have a dedicated implementation outside core : For this project the most important parts will be /core/libs/database/engine which will includes all parent classes for 3 DK databases (core, thumbs, faces). All of these are located repectively in core/libs/database/coredb, core/libs/database/thumbsdb, and core/libs/facesengine/facedb. This last one is outside core/libs/database for compilation reasons due to OpenCV dependency. For each databases (core, thumbs, faces), the /core/libs/database/engine provide classes to : - access through a singleton : facesdbaccess.h for ex. - a wrapper to Database type (sqlite, local mysql, remote mysql) : facesbackend.h for ex. This one will init the database in memory accordingly with settings. This one load the right schema. Most of implementation are give by parent classes in core/libs/database/engine - a schema updater to host porting rules from old to new schema versions : facesdbschemaupdater.h - a specific implementation dedicated to host relevant tasks : facesdb.h for ex - a specific implementation dedicated to host grouping DB tasks : facesdboperationgroup.h for ex The ex given to FacesDB is the most simple to start because the implementation is not too complex. Look alos the ThumbDB which is simple too. The most complex DB implementation is CoreDB, where you will found same king of classes plus more one to delegate specific tasks. The CoreDB is the most huge database (schema), with a lots of triggers between tables. In core/libs/database/, outside core, thumbs DB, you have these sub directories : - collection which host classes to handle the digiKam collections (root albums, local, remote, removable). You will need to take a look later certainly, this depend of reports from bugzilla to fix. - dbjobs which is a multi-threaded/multi-core low level interface dedicated to query the database. No need to touch it for the moment, this work well. - haar which is dedicated to host image similarities fingerprints. This is out of your project. - imagehistory which is dedicated to host image tree-histories accordingly with corrections applied to image by editor and BQM. This is out of your project. - imgqsort which is dedicated to host image algorithm to sort images accordingly with noise,exposure, sharp level, etc. This is out of your project. - items which is dedicated to host classes for image properties. You will need to take a look later certainly, this depend of reports from bugzilla to fix. - servers which are low level classes for mysql local server. Later we will certainly write new one for PostGreSql. This is out of your project. - tags which is dedicated to host classes for virtual album as tags. You will need to take a look later certainly, this depend of reports from bugzilla to fix. - utils where you will found some miscs classes as DB settings widgets and dialogs. This respond partially to your question ? BEst Gilles Caulier 2016-02-29 2:10 GMT+01:00 Varun Gupta <[hidden email]>:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Hello Varun,
once you integrated changes/improvements, I would be happy to help testing. Thus, if I don't get active by myself, just give me a hint. Usually, I use a dedicated MySQL server also for hosting the three Digikam databases. But currently, MySQL support in Digikam master is - subjectively perceived from the perspective of a user - 10 to 15 times slower than SQLite and some things are broken. Thats why I had to switch to SQLite. For testing, I could rescan a large collection, including several face tags, and populate those databases. Regards Felix / fekepp On 29.02.2016 09:28, Gilles Caulier wrote: > In core/libs/database, the README file give some description for each > sub-directories : > > https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/database/README > > As i said previously, DK use 3 Databases (core, thumbs, faces), with 3 > differents schemas. For these 3 databases, we have 3 backends : > > 1/ sqlite, > 2/ local mysql server > 3/ remote Mysql > > For the 2/, we have a dedicated implementation outside core : > > https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/show/databaseserver > > For this project the most important parts will be > /core/libs/database/engine which will includes all parent classes for 3 > DK databases (core, thumbs, faces). All of these are located repectively > in core/libs/database/coredb, core/libs/database/thumbsdb, and > core/libs/facesengine/facedb. This last one is outside > core/libs/database for compilation reasons due to OpenCV dependency. > > For each databases (core, thumbs, faces), the /core/libs/database/engine > provide classes to : > > - access through a singleton : facesdbaccess.h for ex. > - a wrapper to Database type (sqlite, local mysql, remote mysql) : > facesbackend.h for ex. This one will init the database in memory > accordingly with settings. This one load the right schema. Most of > implementation are give by parent classes in core/libs/database/engine > - a schema updater to host porting rules from old to new schema versions > : facesdbschemaupdater.h > - a specific implementation dedicated to host relevant tasks : facesdb.h > for ex > - a specific implementation dedicated to host grouping DB tasks : > facesdboperationgroup.h for ex > > The ex given to FacesDB is the most simple to start because the > implementation is not too complex. Look alos the ThumbDB which is simple > too. The most complex DB implementation is CoreDB, where you will found > same king of classes plus more one to delegate specific tasks. The > CoreDB is the most huge database (schema), with a lots of triggers > between tables. > > In core/libs/database/, outside core, thumbs DB, you have these sub > directories : > > - collection which host classes to handle the digiKam collections (root > albums, local, remote, removable). You will need to take a look later > certainly, this depend of reports from bugzilla to fix. > - dbjobs which is a multi-threaded/multi-core low level interface > dedicated to query the database. No need to touch it for the moment, > this work well. > - haar which is dedicated to host image similarities fingerprints. This > is out of your project. > - imagehistory which is dedicated to host image tree-histories > accordingly with corrections applied to image by editor and BQM. This is > out of your project. > - imgqsort which is dedicated to host image algorithm to sort images > accordingly with noise,exposure, sharp level, etc. This is out of your > project. > - items which is dedicated to host classes for image properties. You > will need to take a look later certainly, this depend of reports from > bugzilla to fix. > - servers which are low level classes for mysql local server. Later we > will certainly write new one for PostGreSql. This is out of your project. > - tags which is dedicated to host classes for virtual album as tags. You > will need to take a look later certainly, this depend of reports from > bugzilla to fix. > - utils where you will found some miscs classes as DB settings widgets > and dialogs. > > This respond partially to your question ? > > BEst > > Gilles Caulier > > > 2016-02-29 2:10 GMT+01:00 Varun Gupta <[hidden email] > <mailto:[hidden email]>>: > > I have finished with reading the code in the folder collection and > coredb from link [1]. I got familiar with the code but I guess there > is lots of code to read , so it would be helpful if you could > redirect me to the parts which are immediately essential so I get > the understanding of the important parts and then go on with the > rest of the code. > > Regards, > varun > > On Sun, Feb 28, 2016 at 4:49 PM, Gilles Caulier > <[hidden email] <mailto:[hidden email]>> wrote: > > Any feddback here. Did you checkout code and look in DB > interface implementation ? Any questions ? > > Best > > Gilles Caulier > > 2016-02-24 22:07 GMT+01:00 Gilles Caulier > <[hidden email] <mailto:[hidden email]>>: > > > > 2016-02-24 21:42 GMT+01:00 Varun Gupta > <[hidden email] <mailto:[hidden email]>>: > > I have started looking at the code from the given link > [1] . I still have doubts what do you mean by the last > stage , in the doc do i have to list all the main > problems that need to be fixed for MYSQL types? > > > Exactly. Accordingly with Agile method, bugzilla is the > reference to evolute and fix open source application. I > already review and sort all entries in bugzilla (including > duplicates) about MySql support. It will be not to hard to > list the main dysfunctions about Mysql support depending of > users contexts reported. Of course, there is an order to fix > the problem due to interdépendances between tasks to patch > the current implementation of database interface. > > Gilles Caulier > > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] <mailto:[hidden email]> > https://mail.kde.org/mailman/listinfo/digikam-devel > > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] <mailto:[hidden email]> > https://mail.kde.org/mailman/listinfo/digikam-devel > > > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Varun, Any progress here ? Any pending questions ? Gilles Caulier 2016-02-29 10:49 GMT+01:00 Felix Leif Keppmann <[hidden email]>: Hello Varun, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Yeah i am done with thumbsdb and facesengine, still have to go through coredb. No questions for now, if I get any problems with coredb i wll post questions soon On Fri, Mar 4, 2016 at 3:33 PM, Gilles Caulier <[hidden email]> wrote:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
ok fine... Gilles Caulier 2016-03-06 4:17 GMT+01:00 Varun Gupta <[hidden email]>:
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |