Re: [Gramps-devel] dbdjango

[Doug B. <dou...@gm...>]

On Fri, Aug 28, 2009 at 9:32 AM, Benny Malengier
<ben...@gm...>wrote:

> 2009/8/28 Gerald Britton <ger...@gm...>:
> > fwiw you can always call
> >
> > .db.person_map[key] or .db.person_map.get(key) which goes directly to
> > the underlying database object.  However, _then_ you need to know the
> > names ot the attributes person_map, place_map etc.  though they're not
> > hard to remember.  I'm also working on an abstraction layer for that
> > access so that the "underlying database" can be anything that supports
> > dictionary-like methods, including, well, a Python dictionary (!) for
> > a simple in-memory database (could be handy for debugging or doing
> > something without leaving a trace on disk.)
>
> I'm not sure you should put so much effort in this or that this is
> even a good thing. Certainly possible.
>
> It's a question of design: how do we want plugin writers to access our
> data? Using the gen.lib methods, or directly via the db methods? There
> is no need to offer two ways of doing things.


Unfortunately, there are already two ways of doing things (fast access and
regular access), and thus this requires one to implement both to be able to
change the backend.

Perhaps Benny's idea of the delayed access can server as the basis for the
fast access, which would allow us to get rid of the hacky, position-based
"abstraction". These details have leaked too much away from the underlying
implementation.

Just saw Gerald's followup... looking forward to seeing this abstraction.

-Doug


>
> We should encourage users to do
>
> person = db.get_person_from_handle
> gid = person.gramps_id
>
> and not
>
> persondb = db.get_person_map[key]
> gid = persondb[Person.POSGID]
>
> The last will work just fine, but means we propagate the bsddb layout
> scheme into all the plugins of GRAMPS. That is just wrong. We should
> discourage it.
>
> So, we don't want users to access the position in the database map
> outside of gen.db classes, as that is a maintenance nightmare.
> A lookup of Person(key=handle) is interesting in that present
> gen.db.base.py does not need to offer a method to do that, it can just
> provide get_person_from_handle, which dbdir implements as a datamap
> lookup which is pumped in a Person class, while dbdjango would
> implement it as an sql query returning a django model that is pumped
> into a Person class.
>
> At the moment we use in some cases directly db methods for performance
> reasons. However, this just makes it more difficult to change the db
> layout or to plug in another backend.
>
> So if you do dictionary based methods, make sure it is done only in
> implementation of the base methods on a backend that can provide this
> functionality, and don't add it to the 'abstract' api as an sql
> backend might not have the functionality to implement this.
>
> So to wrap up, I see gen.db as a way to obtain gen.lib objects. We
> should remove access to underlying data structures everywhere in
> GRAMPS except in the most performance critical places. If those excist
> (building person view tree model eg), switches depending on the
> backend would be needed if multiple backends are supported. Being able
> to avoid those by changing gen.lib in such a way that obtaining
> gen.lib objects from gen.db is no longer a CPU hogger by using delayed
> access would be a nice improvement.
>
> Benny
>
> > On Fri, Aug 28, 2009 at 6:10 AM, Benny
> > Malengier<ben...@gm...> wrote:
> >> 2009/8/28 Doug Blank <dou...@gm...>:
> >>>
> >>> Yes, that sounds like a viable plan. In fact, such a lazy query lookup
> might
> >>> be useful in GRAMPS gtk. (For example, I suspect that deserializing an
> >>> entire Person data might be more than is needed, if you are just
> interested
> >>> in one's name. Might be useful to delay parts of the deserialize
> process.).
> >>
> >> Why did I not think of that myself? That sounds like a great way to
> >> obtain a free speed boost. On deserialize of the person I do in
> >> unserialize:
> >> self._media_list = datamap[POS_MEDIALIST]
> >>
> >> and only on access of self.media_list the data of self._media_list
> >> itself is deserialized.
> >>
> >> I have to write the default engine anyway, I can do it that way. It
> >> might even mean we can do away with the complicated building of models
> >> for eg the person view directly from the datamap to avoid all the
> >> deserializes (well, probably not on the person view, but in other
> >> places ... ).
> >>
> >> Once there is an engine accessible, one could even go one step further
> >> and not do
> >> person = db.get_person_from_handle(handle).
> >>
> >> But instead add a method to allow for:
> >>
> >> person = Person(key=handle), and the Person object queries the engine
> >> to obtain this person.
> >> Well, that would be a break from how things are done now and probably
> >> another design choice, but the fact a plugin writer needs to know the
> >> gen.db access methods has always struck me as an extra layer of
> >> complexity one has to learn. Anyway, this is not something I'll
> >> pursue, only the delayed access is what I want to add to gen.lib.
> >>
> >> Benny
> >>
> >>
> ------------------------------------------------------------------------------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> >> trial. Simplify your report design, integration and deployment - and
> focus on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gra...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
> >
> >
> >
> > --
> > Gerald Britton
> >
>