From: <ben...@ug...> - 2007-01-19 10:41:39
|
Quoting Richard Taylor <rjt...@th...>: > If someone is going to embark on the task of constructing a nice Pythonic OO > interface layer that combines the GrampsDb and RelLib modules then I think > they should keep it as a layer on top of these and not seek to drastically > change what we already have. I can see the potential for a module structure > like this (switch to fixed width font): > > > |-------------| |-------------| > | Plugin | | Core GUI | > |-------------| |-------------| > ^ ^ ^ ^ > | | | | > | v v | > | --------------- | High Level API > | |-------------| | > | | New Model | | > | |-------------| | > | ^ ^ | > | | | | > v v v v > -------------------------------- Low Level API > |-------------| |-------------| > | GrampsDB | | RelLib | > |-------------| |-------------| Great. I think one could use for the new model one of the interfaces of the existing SQL object db api's. Eg Django, bazar. The new model would have to convert the requests to Grampsdb/Rellib. An SQL backend would then mean making a real django model of gramps with SQL tables, and convert the requests to this model (so changing the entire low level api, which with Django is essentially just some config files of how the tables look like, and let it generate automatically). That would be easier than implementing another backend of GrampsDB as SQL, as that is more lowlevel than an SQL interface is. I personally have no problem converting the BSDDB to a relational database in my head. So, anybody now/has experience with an SQL object model in python, which is quite stable? Benny > There may be a need to augment the Low Level API but the strict separation > should be maintained. This would ensure that we don't have to make large > changes to the existing code and we can still dip into the Low Level API when > optimisation requirements make require it. It would also mean that the New > Model could be targeted at other DB or even RelLib implementations if anyone > ever wanted to do that. > > Regards > > Richard > > > On Thursday 18 January 2007 22:35, ben...@ug... wrote: >> Hi, >> >> first, don't like the GRAMPS 3000 name. Like Python 3000, coming in a >> year we'll >> never see... >> >> second, I don't want to defragment the gramps effort. I'd like to finish my >> plugin (this year), perhaps some webstuff, ... . Nevertheless, foundations >> are important, and if we can add a module to gramps to make life easier, >> why not. >> >> third, I now too little of the GRAMPS database to form an opinion on the >> implementation. I can only argue about how I have to use stuff to write a >> plugin or tool. >> >> My opinion is very different from present GRAMPS implementation. I always >> learned the objects should hide the database. I have done some googling to >> python DB API's to look at examples. >> >> I like things like in django (a MVC model see >> http://en.wikipedia.org/wiki/Model-view-controller): >> See eg: >> http://www.djangoproject.com/documentation/tutorial1/#creating-models So: >> p= Apple(color='red') >> p.save() >> allapples = Apple.objects.all() >> >> Yes, the object hide database. Logic can be added to Apple through methods. >> >> GRAMPS works more like bazaar (found via >> http://wiki.python.org/moin/HigherLevelDatabaseProgramming): >> See eg:http://www.nongnu.org/bazaar/ (scroll down to application code) >> So: >> apple = Apple() >> apple.color = 'red' >> db.add(apple) >> >> There is one big difference however: db here does not itself know it >> contains apples, and not one method in db will have the word apple in it. >> Db can insert, >> del, lookup, .... All geneneral names: >> http://www.nongnu.org/bazaar/public/bazaar.core.Bazaar-class.html >> The advantage: you learn what db does (easy), and you work with the >> objects from >> then on, always in the same way. This corresponds to what a database >> actually is. >> >> Moreover, if you look at bazar (or >> http://modeling.sourceforge.net/UserGuide/), >> you see things that gramps misses, especially easy access to associations, >> like: >> family.father = papa >> del family.father #this breaks the association, does not delete father! >> db.delete(papa) #this can be set up to delete father and all references to >> it family.father = papa >> See also fetching: >> people=db.fetch('People', qualifier='lastName=="Hugo"') >> >> >> The above two models I like, with preference for the first (probably due to >> my programming history), and I understand that both are rooted in the >> relational database world. >> >> So, in short, db.get_main_parents(person), looks wrong for me. In terms of >> Django or Bazaar, I'd like >> Family.objects.get(pk=person.main_parent_family_handle) >> or >> db.get('Family', handle = person.main_parent_family_handle) (I know, this >> is possible in GRAMPS, however, all other methods exist too.) >> >> I don't know, it's just that as a programmer starting in GRAMPS you have >> the impression you need to know RelLib, and that you have to go over all >> grampsdbbase too. >> >> Just some food for thought. The database is probably forced like this due >> to BSDDB, and little can be changed about it. I will have no time to >> seriously implement (or it should be you can wait several years for the >> result ;-) ) >> >> Benny >> >> Quoting Alex Roitman <sh...@gr...>: >> > On Thu, 2007-01-18 at 18:54 +0000, Richard Taylor wrote: >> >> This is not really true, the UI is decoupled from the DB through the >> >> GrampsDB >> >> interface. The use of handles is also not something that gets in the >> >> way of a >> >> DB backed, the handles would just be an indexed column on the tables. >> >> The real issues with a database backend is the mapping of the RelLib >> >> Objects into >> >> a relational schema. The current model serialises the objects and puts >> >> them into the database as key/value pairs where the key is the handle >> >> and the value is the serialised python object. >> > >> > Actually, this is not quite true in 2.2. We serialize a tuple, not a >> > custom python object. Great pains were taken to only serialize tuples >> > of the builtin python objects, that is: numbers, strings, lists, tuples, >> > None, and True/False. That way the saved data is not tied to any >> > particular classes. >> > >> > But to the topic -- yes, these serialized tuples may have nested >> > tuples, and so on. Not a flat table structure. >> > >> >> To take advantage of an SQL database it would be necassary to design >> >> an object >> >> relational mapping for the RelLib objects and to implement the >> >> marshalling/unmarshalling of the objects into that mapping. >> > >> > Exactly. Once you know how to organize the tables, it should be >> > easy to extract data from the tuple. But it has to be on the fly >> > for every access/write. >> > >> >> The other really big job would be to make all the filter/search >> >> functions in gramps use an abstract interface so that they could be >> >> implemented in different ways for different databases. This can be done >> >> but it is a big job. >> >> >> >> I think that you have to be really, really sure that you want to >> >> take this on. >> > >> > Yeah. So it would be a kind of effort that goes into pygtk, which >> > becomes the platform in itself. If/when we're at that point, we >> > could ship python-gramps packages and let everybody use them in whatever >> > programs :-) >> > >> > Cool, but the downside is that it takes an enormous amount of work >> > and maintenance. >> > >> > -- >> > Alexander Roitman http://www.gramps-project.org >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |