5,850
edits
Changes
m
Protected "GEPS 017: Flexible gen.lib Interface": withdrawn no edit to be done as historical ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))
{{man warn|This proposal has been withdrawn.|'''Update''': After building a [[Media:prototype.tar.gz|prototype]], it was found to be too slow for general use. Rather, it seems to be better to cache the data as it appears when it comes from the BSDDB database (pickled, serialized versions of gen.lib objects).}}
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.
''The prototype uses a combination of Delayed evaluation, and removing of gen.lib objects' properties. When a property was accessed, the delayed object was evaluated, and the set to the attribute.''
= Overview =
self._engine = EngineKeeper.get_instance().engine
Note that above should be done with properties, so that _engine is only obtained when requested and still None. Note also that all gen.lib obects objects should perhaps use __slots__ to reduce memory footprint.
When not yet initialized attributes are needed, the engine is requested for the data. For example the marker attribute of a person, which is a MarkerType() object. Eg, the code fragment
In the worst case unpack needs to work likewise.
==== getters and setters ====
The typical get and set methods in gen.lib would be deprecated. For 3.3 it would print a Deprecated warning, for 3.4 they should be completely removed.
==== bsddb get_raw methods ====
The get_raw_person_data and friends methods would become private/protected to the bsddb. They should not be used outside gen.db, so the code in the models will no longer depend on it, allowing for a backend based on another bsddb schema or another database
=== Advantages ===
The advantages of this approach are:
* the delayed access is behind the scenes, and via a standard easy to understand mechanism. The hard part of obtaining data is all in the db code in gen.db, and the engine code for a db in gen.lib.
* we can move more freely to another database schema. This might be several things: add bsddb tables, or use an sql backend. Upgrade of bsddb could even be done while supporting still normal read of the old bsddb layout (so without expensive upgrade before you can access the data). The only thing that would be needed is write a new engine for the new schema. As an example, suppose we add type tables to store all used custom types, then this change to bsddb can be done without influence on how gen.lib works. In the present setup serialize/unserialize must be changed.
* In the future, the engine could be used for more advanced stuff. Eg, doing Person().obtain(name="McDonald") could be implemented. In that case, obtain accesses the engine and does the query. Note that this is ''not'' the aim of the change, it is just a remark that this is a possibility.
= References =
# - [httphttps://oldsourceforge.nabble.comnet/p/gramps/mailman/message/24262998/(Gramps-devel) LazyEvaluation in Gramps] From: Doug B. -Evaluation2009-in12-Gramps28 06:37:38 -ts26940237.html mailing list discussion# - {{bug|3476}}: [patch]An experiment in lazy evaluation in gramps# - [httphttps://www.gramps-project.org/bugsblog/view.php?idp=3476 Lazy experiment (patch)211 Alternative Interfaces] January 23rd, 2010 by Doug Blank - Gramps Blog post discussing ideas [[Category:GEPS|F]]