From: <ben...@ug...> - 2007-01-18 22:36:22
|
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. |