GEPS 017: Flexible gen.lib Interface

From Gramps
Revision as of 19:59, 31 December 2009 by Dsblank (talk | contribs) (Possible Fixes)
Jump to: navigation, search

gen.lib is the Python interface for all of the objects in Gramps. Currently, it is not directly tied to any data storage mechanism, except for the implicit assumption that objects are created through an unserialize method for each object.

This proposal explores the possibility of making the creation of objects more general, and less tied to the particular unserializing process.

Overview

Currently, the main database interface for getting an object looks like:

>>> db.get_person_from_handle(handle)

This uses the only existing manner of creating a person supported by gen.lib:

>>> Person().unserialize(data)

where data is a serialized (non-object) representation of a Person.

This has two issues:

  1. it may unserialize data that isn't needed
  2. it only allows data to be created in this particular manner

This proposal would allow for an alternative gen.lib construction.

Possible Fixes

In the detailed mailing-list discussion [1], there were four possible solutions dicussed:

  1. If an alternative is needed, use something outside of gen.lib
  2. Using a lazy() wrapper to only evaluate what is necessary
  3. Explicit delayed unpickling
  4. Use an Engine inside each object to retrieve data when necessary

#1 Replicate

Replicating gen.lib has the benefit of having zero impact on the current gen.lib. However it would require two separate code paths to maintain, and does nothing to address unnecessary unpickling in BSDDB.

#2 Lazy Wrapper

The lazy wrapper idea was shown to have some savings in postponing unserializing (see patch in bug report [2]). However, the requirement to wrap all data in lazy(), and the unintended side-effects were too great a cost.

#3 Explicit delayed unpickling

Just save the data of substructure until you need to unserialize it. This is still based on pickling and is limiting in future approaches.

#4 Engine

The best choice considered so far is to build an invisible engine into the gen.lib framework.

[2] - http://www.gramps-project.org/bugs/view.php?id=3476

References

  1. - http://old.nabble.com/Lazy-Evaluation-in-Gramps-ts26940237.html