> 2008/12/2 Joe Kraft
>> Douglas S. Blank wrote:
>> > [email protected] wrote:
>> >> I would love to see the gramps db migrate to a sql backend. Would
>> >> sharing data much easier. What I would do is have my database on my
>> >> public web server and use the gramps frontend on each desktop to it.
>> >> This would also allow me to write my own web reports without having
>> >> know Python.
>> > (Another possible output format is the PhdGedView SQL format. I'm not
>> > familiar with the details, but that would also allow you to use
>> > PhdGedView and write SQL queries. But *my* target is a fully-GRAMPS
>> > compatible SQL format.)
>> > -Doug
>> I apologize in advance for the shot from the lurker...
>> This gets very close to what I was looking for in a geneology program
>> was searching a few months ago. I wanted something that could be used
>> which is web based like PhpGedView, but allow downloading and
>> the database to a laptop when I'm operating without an internet
>> When I'm back at home I can sync all the changes back to the main
>> I can do portions of that now, with some effort, by using various export
>> tools. But none I've tried so far will deal with the whole database
>> including media files and such.
>> I think overall an addition of an SQL based backend will help pave the
>> for me to link things up the way I'd like when I have time to work on
>> in a few months.
Thanks for the comments. Some discussion below.
> I would like to point out that the present database GRAMPS has is capable
> multiple users, and can be used as a backend to a webserver.
> The reason it cannot be used like that now is because this is not
> implemented, not because we do not use an SQL database.
This is true, of course. But I think it misses the main point: in order
for someone to be able to tap into the GRAMPS database to do a simple
add-on application (say a webpage listing) requires a huge amount of
knowledge. SQL makes this so much easier as the data is self-defining to a
degree. It will still take some information, but if you are just slightly
familiar with SQL (and had an example) you could probably put together a
query in just a few minutes. We are currently preventing this niche of
> There is no reason to believe the present developers could do what people
> expect in this thread because suddenly the backend is SQL, on the
> changing the backend to SQL will probably mean the project is not moving
> a year or so while the new version with new backend would stabilize. Is
> really what users want?
This might be true. But, I truly believe that once we got beyond that
point, GRAMPS could developer faster, would be more stable, and would open
up the data for far more uses by more people.
> I would like to repeat my suggestion:
> 1/set up a repository for a project, eg on google code/sourceforge. I
> have a name ready: 3branchWeb :-P
> 2/copy /gen/lib/ from GRAMPS over, so the objects of Gramps are known in
> this app
> 3/write a datamodel for the data in SQL format. I would suggest Django.
> Write a backend to /gen/lib over this datamodel with the things we want
> for plugins to work, ....).
> 4/code, code, code, or in more famous words: developers, developers,
> developers. Point is, the developers doing client-server and sql are
> probably different from present GRAMPS developers
> 5/If it works out, see if it can be part of the GRAMPS project
> jointly develop the /gen/lib and xml format, the first being present as
> site-package install in python. Work out merge/import together.
That sounds like a plan, and more detail than you provided before. I'm
still in the stage of understanding the data in order to do step 3, write
a data model. I'm not really interested in going off by myself and working
on this... tried something similar before :)
> The idea of writing an export to SQL from GRAMPS is the wrong way to
> this in my opinion.
That might be because you already know the database layout and can parse
XML. I'm more familiar with Python code, and a bottom-up approach. But
they should both lead to the same point, right?
> The best way of interaction between such programs is
> the xml format (export in gramps, import the xml from a web interface or
> command line to the server running the SQL), so the SQL export is useless
> this scheme in the long run (it serves only as a primer to see how a
> database would look like).
It isn't useless to me... I'm learning a lot about the GRAMPS DB layout,
and found some bugs in (my) current GRAMPS code. That will be useful,
especially if we continue using BSDDB. This code is also useful for going
to a any relational framework. And the SQL data can also be imported to
re-create the exact same GRAMPS BSDDB as it preserves the exact handles.
But I don't understand why deconstructing the current GRAMPS DB couldn't
lead to the same data model that you would get by translating the XML?
Wouldn't this SQL database be the model?
I do understand that you, Brian... all the developers really--- have
invested a lot of time developing and maintaining the current database
system. I'm not ready to make a 180 degree turn, but I do think this is
worth exploring without dismissing it out of hand.
Thanks again for the feedback,
This SF.Net email is sponsored by the Moblin Your Move Developer's
Build the coolest Linux based applications with Moblin SDK & win great
Grand prize is a trip for two to an Open Source event anywhere in the world