Don> I've been giving some thought to changes after the 1.0
Don> release. The biggest issue is going to be moving to a real
Don> database.
I think it will be a big win overall, but mostly in terms of memory
used, which is pretty ugly right now.
Don> Currently, GRAMPS has an experimental ZODB interface. This
Don> interface has never been the best, and had never been stable. I
Don> think it would probably be wise to remove the interface for the
Don> 1.0 release.
Hear hear!
Don> 1) Choice of database. I would prefer a simple to setup database.
Don> I'd rather not have Aunt Martha get frustrated because she has to
Don> configure a database server. Ideally, no additional software
Don> would have to be loaded. Currently, I'm favoring the bsddb
Don> interface. It is standard in python 2.3, and does not require any
Don> complex setup.
Hear hear! And if you can package it in with Gramps by default, so
that user's don't even need to know it's there, that's even better.
Don> 2) The database is going to have to be modified to eliminate all
Don> references to other objects, and using GRAMPS IDs as keys. This
Don> will allow us to only load objects that we need as we need
Don> them. The person/family objects are going to have to be
Don> fixed. Currently, families keep a list of people, and people keep
Don> lists of families. This will have to be changed so that lists of
Don> IDs are kept. (References won't work, since the objects won't be
Don> in memory)
I'm not sure you'll have to do this. Can't you keep different objects
in different tables, with cross references between them? In any case,
good DB programming requires that you use unique keys for each table,
even if the data in them is supposedly unique. If you guess wrong
about your data, you're ok.
This means that the re-writting of the gramps back end is a good time
to maybe abstract out how data is handled internally, so we can put in
a proper data model here.
I guess I really need to learn python and spend the time understand
gramps internally. Good thing it's winter and I'll be inside more
now. :]
Back to the references issue. Can you describe the current schema
used for gramps and how it stores records/objects currently? Just
from looking at the XML file from an 0.8.0-pl2 version of the code
(it's what I had handy), you've got the following objects:
People
Families
Events
Places
Sources
And they all look to use the proper keys to reference each other.
This looks good. I'm probably missing the internal issues though...
Don> 3) When does data get updated? Do we move to a mode where data is
Don> updated as changed? This is how most databases (and genealogy
Don> programs) work.
I would suspect that you'd want to write changes to disk once they are
made. Don't keep them in memory except for caching reasons.
Don> However, if we are still working with an XML database, we will
Don> have to have the load/save model. Would this be confusing?
Why would we want to keep the XML DB around after 1.0 realease? It's
going to be a big enough change that I think it should be just dropped
completely.
What advantages do you see for the XML interface? The only one I see
is that the DB is in a human readable format, but it would be easy
enough to have an import/export filter for XML formated files. But
the internal setup should be purely based on a DB format.
John
|