Lock files for sqlite and postgresql

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Lock files for sqlite and postgresql

Nick Hall
Devs,

Currently we don't use lock files for sqlite and postgresql. This can
lead to loss of data.  For example:

1. User A opens the person editor and makes some changes.
2. User B edits the same person and saves some changes.
3. User A clicks "OK" to save their changes.  The changes made by user B
are lost.

How do we want to protect against this?

For sqlite, we could use a similar approach to BSDDB, but for postgresql
we need to store the lock in a database table.

We also have a problem with the last accessed timestamp on postgresql. 
At the moment we just touch a local dummy file called "meta_data.db".

Any opinions?

After we solve this problem we can probably go ahead with our first beta
release.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

John Ralls-2


> On Nov 27, 2017, at 3:16 AM, Nick Hall <[hidden email]> wrote:
>
> Devs,
>
> Currently we don't use lock files for sqlite and postgresql. This can lead to loss of data.  For example:
>
> 1. User A opens the person editor and makes some changes.
> 2. User B edits the same person and saves some changes.
> 3. User A clicks "OK" to save their changes.  The changes made by user B are lost.
>
> How do we want to protect against this?
>
> For sqlite, we could use a similar approach to BSDDB, but for postgresql we need to store the lock in a database table.
>
> We also have a problem with the last accessed timestamp on postgresql.  At the moment we just touch a local dummy file called "meta_data.db".
>
> Any opinions?
>
> After we solve this problem we can probably go ahead with our first beta release.


Nick,

The ideal solution is to use the database’s built-in concurrency, but it’s a bit tricky. The Berkeley DB manual has an excellent section on the intricacies that I recommend reading if you decide to implement it.

The quick alternative that I used in GnuCash is to add a lock table to the database. At it’s simplest it can contain a single row with a single boolean column; for more detail you could add user, host, or pid information and display that in the Family Trees window next to the lock.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

dave.khuon@gmail.com
One possible (generic) solution that I remembered, way back when, was to use the last update datetime (in UTC) of the 'row'.

Any time a user's process needs to save it's data which includes both new and old datetimes, the update clause would include a match of the old datetime as well as other qualifying keys.  If the update was successful, everything is good.  Otherwise, it is the responsibility of this process to notify the user that data that he/she originally worked with have been changed prior to his/her commit.  Insert will be handled in similar manner.

The user then will have to decide which pieces of data he/she wants to change.  Not sure this scenario applies here, in this environment.

On Nov 27, 2017 9:14 AM, "John Ralls" <[hidden email]> wrote:


> On Nov 27, 2017, at 3:16 AM, Nick Hall <[hidden email]> wrote:
>
> Devs,
>
> Currently we don't use lock files for sqlite and postgresql. This can lead to loss of data.  For example:
>
> 1. User A opens the person editor and makes some changes.
> 2. User B edits the same person and saves some changes.
> 3. User A clicks "OK" to save their changes.  The changes made by user B are lost.
>
> How do we want to protect against this?
>
> For sqlite, we could use a similar approach to BSDDB, but for postgresql we need to store the lock in a database table.
>
> We also have a problem with the last accessed timestamp on postgresql.  At the moment we just touch a local dummy file called "meta_data.db".
>
> Any opinions?
>
> After we solve this problem we can probably go ahead with our first beta release.


Nick,

The ideal solution is to use the database’s built-in concurrency, but it’s a bit tricky. The Berkeley DB manual has an excellent section on the intricacies that I recommend reading if you decide to implement it.

The quick alternative that I used in GnuCash is to add a lock table to the database. At it’s simplest it can contain a single row with a single boolean column; for more detail you could add user, host, or pid information and display that in the Family Trees window next to the lock.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Nick Hall
In reply to this post by John Ralls-2
On 27/11/17 15:12, John Ralls wrote:
> The ideal solution is to use the database’s built-in concurrency, but it’s a bit tricky. The Berkeley DB manual has an excellent section on the intricacies that I recommend reading if you decide to implement it.

I wasn't planning to make any changes to the lock file in the BSDDB backend.

>
> The quick alternative that I used in GnuCash is to add a lock table to the database. At it’s simplest it can contain a single row with a single boolean column; for more detail you could add user, host, or pid information and display that in the Family Trees window next to the lock.

For postgresql, a lock table is a good idea.

We could add lock methods to the database API with a database specific
implementation.

A similar approach would work for the last accessed time.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Nick Hall
In reply to this post by dave.khuon@gmail.com
On 27/11/17 16:09, Dave Khuon wrote:
One possible (generic) solution that I remembered, way back when, was to use the last update datetime (in UTC) of the 'row'.

Any time a user's process needs to save it's data which includes both new and old datetimes, the update clause would include a match of the old datetime as well as other qualifying keys.  If the update was successful, everything is good.  Otherwise, it is the responsibility of this process to notify the user that data that he/she originally worked with have been changed prior to his/her commit.  Insert will be handled in similar manner.

The user then will have to decide which pieces of data he/she wants to change.  Not sure this scenario applies here, in this environment.

That approach would work for primary objects.  However, there is still a problem with metadata and undo/redo.

The metadata is read at the start of a session and only written back when the database a closed.  Things like bookmarks and custom types are likely to be lost.  This could be fixed by updating the database as soon as changes are made.

The undo/redo holds a list of snapshots locally.  Either this would have to be moved to the server or we would have to store diffs instead of snapshots.  This needs further discussion.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

John Ralls-2
In reply to this post by Nick Hall


> On Nov 28, 2017, at 2:50 AM, Nick Hall <[hidden email]> wrote:
>
> On 27/11/17 15:12, John Ralls wrote:
>> The ideal solution is to use the database’s built-in concurrency, but it’s a bit tricky. The Berkeley DB manual has an excellent section on the intricacies that I recommend reading if you decide to implement it.
>
> I wasn't planning to make any changes to the lock file in the BSDDB backend.

I know. I recommend that section of the Berkeley DB manual because it’s a good discussion of database locking strategies and what you need to take into consideration when selecting and implementing  one.  It does also talk about the implementation details for Berkeley DB, but you can skim over those parts.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Nick Hall
On 28/11/17 14:46, John Ralls wrote:
> I know. I recommend that section of the Berkeley DB manual because it’s a good discussion of database locking strategies and what you need to take into consideration when selecting and implementing  one.  It does also talk about the implementation details for Berkeley DB, but you can skim over those parts.

Do you mean chapter 18 in the developer reference?

https://docs.oracle.com/cd/E17076_05/html/programmer_reference/lock.html

This could be useful if we decide to implement object locking at the
application level.

In the short-term, for v5.0, I suggest that we only support single-user
access.  For sqlite, we could use a lock file as we do for BSDDB.  For
postgresql, we need something like a simple lock table on the server. 
The problem is that it isn't really acceptable to present the user with
a login dialog for each postgresql database when the family tree manager
is opened.

One solution would be to leave the lock or last accessed columns empty
in the family tree manager for postgresql databases.  We could issue a
warning when the database is opened.

Do we want to aim to support multi-user access in v5.1?  If so, we need
to decide how we handle two users editing the same person
simultaneously.  There seem to be three options:

1. Application level object locking.
2. Checking timestamps when saving objects.
3. Applying a patch rather then saving a copy of the object.

We will also need to decide how we handle undo/redo.  Do we move the
undo list into a table?

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

prculley
My opinion is that we should NOT attempt to make Gramps multi-user friendly.  I know that there are some that want that functionality,  but I really don't think very many would want to set up real client/server operation on multiple machines.  I don't see usage on a single machine as particularly interesting.

I think that more often users just want to have an easy way to sync multiple machines.  The current locking mechanisms provide some protection against doing that incorrectly.

I know it is fun to play around with databases, but I believe that we could spend our rather limited developer resources on other things.

Paul C.

On Wed, Nov 29, 2017 at 10:16 AM, Nick Hall <[hidden email]> wrote:
On 28/11/17 14:46, John Ralls wrote:
I know. I recommend that section of the Berkeley DB manual because it’s a good discussion of database locking strategies and what you need to take into consideration when selecting and implementing  one.  It does also talk about the implementation details for Berkeley DB, but you can skim over those parts.

Do you mean chapter 18 in the developer reference?

https://docs.oracle.com/cd/E17076_05/html/programmer_reference/lock.html

This could be useful if we decide to implement object locking at the application level.

In the short-term, for v5.0, I suggest that we only support single-user access.  For sqlite, we could use a lock file as we do for BSDDB.  For postgresql, we need something like a simple lock table on the server.  The problem is that it isn't really acceptable to present the user with a login dialog for each postgresql database when the family tree manager is opened.

One solution would be to leave the lock or last accessed columns empty in the family tree manager for postgresql databases.  We could issue a warning when the database is opened.

Do we want to aim to support multi-user access in v5.1?  If so, we need to decide how we handle two users editing the same person simultaneously.  There seem to be three options:

1. Application level object locking.
2. Checking timestamps when saving objects.
3. Applying a patch rather then saving a copy of the object.

We will also need to decide how we handle undo/redo.  Do we move the undo list into a table?

Nick.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Nick Hall
On 29/11/17 19:50, Paul Culley wrote:
> My opinion is that we should NOT attempt to make Gramps multi-user
> friendly.  I know that there are some that want that functionality, 
> but I really don't think very many would want to set up real
> client/server operation on multiple machines.  I don't see usage on a
> single machine as particularly interesting.

I agree.  Multi-user access has never been a goal for the 5.0 release.

>
> I think that more often users just want to have an easy way to sync
> multiple machines.  The current locking mechanisms provide some
> protection against doing that incorrectly.

Currently there is no locking for sqlite or postgresql databases.

>
> I know it is fun to play around with databases, but I believe that we
> could spend our rather limited developer resources on other things.

I don't think it is particularly fun to play around with databases.  I
would far prefer to spend my time implementing new features that assist
my family history research.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Ross Gammon
On 11/30/2017 11:10 AM, Nick Hall wrote:

> On 29/11/17 19:50, Paul Culley wrote:
>> My opinion is that we should NOT attempt to make Gramps multi-user
>> friendly.  I know that there are some that want that functionality, 
>> but I really don't think very many would want to set up real
>> client/server operation on multiple machines.  I don't see usage on a
>> single machine as particularly interesting.
>
> I agree.  Multi-user access has never been a goal for the 5.0 release.
>
>>
>> I think that more often users just want to have an easy way to sync
>> multiple machines.  The current locking mechanisms provide some
>> protection against doing that incorrectly.
>
> Currently there is no locking for sqlite or postgresql databases.
>
>>
>> I know it is fun to play around with databases, but I believe that we
>> could spend our rather limited developer resources on other things.
>
> I don't think it is particularly fun to play around with databases.  I
> would far prefer to spend my time implementing new features that assist
> my family history research.
Hi all,

I thought I would chime in from a user's perspective.

1. Reliability - I have seen quite a few corrupt databases reported on
the Users List, and in the bug tracker. We should do our best to protect
the user against the most basic of mistakes (and be clear what is not
supported in our release announcement).

2. Multi-Machine - this is also common on the User List. I for one would
like to be able to work on my Family Tree on both my desktop machine,
and my laptop. Assuming the (one) user has a way to syncronise, or store
their database centrally, the issue is normally different versions of
Gramps and different versions of Berkeley DB. A recommended way to do
this with the available database options would be nice.

3. Multi-User - I would love to be able to do this, as I have relatives
and collaborators all over the world. But in my opinion, Gramps is not
the only answer here. A web server based approach is required. If Gramps
was able to "talk" with the web based service (Gprime?), so it was
possible to work from a web browser, as well as use Gramps on my desktop
or laptop (without manually importing and exporting data), that would be
wonderful. I appreciate that this is probably beyond 5.0. But I believe
other users would appreciate it (instead of using Ancestry/Family Search
to collaborate).

Regards,

Ross


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Ross Gammon
On 11/30/2017 04:10 PM, Ross Gammon wrote:
> I don't think it is particularly fun to play around with databases.  I
> would far prefer to spend my time implementing new features that assist
> my family history research.

I forgot to say in my previous mail:
Unless we can do multi-machine/user with Berkeley DB, many users will
see multi-machine/user as a worthwhile feature.

Ross


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

John Ralls-2
In reply to this post by Nick Hall


On Nov 29, 2017, at 8:16 AM, Nick Hall <[hidden email]> wrote:

On 28/11/17 14:46, John Ralls wrote:
I know. I recommend that section of the Berkeley DB manual because it’s a good discussion of database locking strategies and what you need to take into consideration when selecting and implementing  one.  It does also talk about the implementation details for Berkeley DB, but you can skim over those parts.

Do you mean chapter 18 in the developer reference?

https://docs.oracle.com/cd/E17076_05/html/programmer_reference/lock.html

This could be useful if we decide to implement object locking at the application level.

Yes, that’s the one.


In the short-term, for v5.0, I suggest that we only support single-user access.  For sqlite, we could use a lock file as we do for BSDDB.  For postgresql, we need something like a simple lock table on the server.  The problem is that it isn't really acceptable to present the user with a login dialog for each postgresql database when the family tree manager is opened.

One solution would be to leave the lock or last accessed columns empty in the family tree manager for postgresql databases.  We could issue a warning when the database is opened.

Some other possibilities:
* Store the credentials so that we ask for them only once. That can be done via the OS’s facility (MacOS calls their’s “Keychain”, I don’t remember offhand what the other two call theirs but I know that all have one) though that I think requires some OS-specific code to implement as each has its own API. 
* Track somehow which databases use the same credentials and ask for each only once and cache them.
* Provide for a more automated authentication method like GSSAPI, Kerberos, or LDAP. See https://www.postgresql.org/docs/9.1/static/auth-methods.html
* Maintain a separate per-server lock database. (Yeah, yuk.)


Do we want to aim to support multi-user access in v5.1? 

Absent a lot of pressure from the users we probably don’t want to go down that rabbit hole. Concurrency is not easy to get right.

If so, we need to decide how we handle two users editing the same person simultaneously.  There seem to be three options:

1. Application level object locking.
2. Checking timestamps when saving objects.
3. Applying a patch rather then saving a copy of the object.

We will also need to decide how we handle undo/redo.  Do we move the undo list into a table?

Let’s not worry about that stuff unless we actually decide to implement multi-user.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Tim Lyons
Administrator
In reply to this post by Ross Gammon
Just to remind people that Doug Blank created a new project 'gprime' from
Gramps specifically to create a web-based application for genealogy.

gprime is here: https://github.com/GenealogyCollective/gprime. it seems to
have been last updated in June 2017. An alpha release and demo was made in
January 2017 (this was the last blog post). See also Gramps GEPS 013:
https://gramps-project.org/wiki/index.php?title=GEPS_013:_Gramps_Webapp
(this doesn't seem to have been significantly updated for several years).



--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-Dev-f1791083.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

Nick Hall
In reply to this post by Ross Gammon
On 30/11/17 15:10, Ross Gammon wrote:

> I thought I would chime in from a user's perspective.
>
> 1. Reliability - I have seen quite a few corrupt databases reported on
> the Users List, and in the bug tracker. We should do our best to protect
> the user against the most basic of mistakes (and be clear what is not
> supported in our release announcement).
>
> 2. Multi-Machine - this is also common on the User List. I for one would
> like to be able to work on my Family Tree on both my desktop machine,
> and my laptop. Assuming the (one) user has a way to syncronise, or store
> their database centrally, the issue is normally different versions of
> Gramps and different versions of Berkeley DB. A recommended way to do
> this with the available database options would be nice.
>
> 3. Multi-User - I would love to be able to do this, as I have relatives
> and collaborators all over the world. But in my opinion, Gramps is not
> the only answer here. A web server based approach is required. If Gramps
> was able to "talk" with the web based service (Gprime?), so it was
> possible to work from a web browser, as well as use Gramps on my desktop
> or laptop (without manually importing and exporting data), that would be
> wonderful. I appreciate that this is probably beyond 5.0. But I believe
> other users would appreciate it (instead of using Ancestry/Family Search
> to collaborate).

Thanks for these comments.

We still don't fully understand why BSDDB get corrupted.  I have been
using Gramps for over 8 years now without any problems.

Gramps opens the database in single-user mode (with the DB_PRIVATE
flag).  Opening again, even with a database tool, will cause
corruption.  Even opening a low-level copy of a database when the
original is open will cause corruption.  This is why we use a lock file.

The new backends allow multi-user access, but Gramps is not designed for
this.  The database should not be corrupted, but data may be lost.  This
is why locking is needs to be added.

I suggest the following:

1. Add lock file support to the dbapi backends.
2. Move the posgresql backend into third-party addons.
3. Enable sqlite for all users and recommend it for multi-machine access.

We can consider adding support for server-based databases and multi-user
access in a future release.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lock files for sqlite and postgresql

John Ralls-2


> On Dec 6, 2017, at 3:57 AM, Nick Hall <[hidden email]> wrote:
>
> On 30/11/17 15:10, Ross Gammon wrote:
>> I thought I would chime in from a user's perspective.
>>
>> 1. Reliability - I have seen quite a few corrupt databases reported on
>> the Users List, and in the bug tracker. We should do our best to protect
>> the user against the most basic of mistakes (and be clear what is not
>> supported in our release announcement).
>>
>> 2. Multi-Machine - this is also common on the User List. I for one would
>> like to be able to work on my Family Tree on both my desktop machine,
>> and my laptop. Assuming the (one) user has a way to syncronise, or store
>> their database centrally, the issue is normally different versions of
>> Gramps and different versions of Berkeley DB. A recommended way to do
>> this with the available database options would be nice.
>>
>> 3. Multi-User - I would love to be able to do this, as I have relatives
>> and collaborators all over the world. But in my opinion, Gramps is not
>> the only answer here. A web server based approach is required. If Gramps
>> was able to "talk" with the web based service (Gprime?), so it was
>> possible to work from a web browser, as well as use Gramps on my desktop
>> or laptop (without manually importing and exporting data), that would be
>> wonderful. I appreciate that this is probably beyond 5.0. But I believe
>> other users would appreciate it (instead of using Ancestry/Family Search
>> to collaborate).
>
> Thanks for these comments.
>
> We still don't fully understand why BSDDB get corrupted.  I have been using Gramps for over 8 years now without any problems.
>
> Gramps opens the database in single-user mode (with the DB_PRIVATE flag).  Opening again, even with a database tool, will cause corruption.  Even opening a low-level copy of a database when the original is open will cause corruption.  This is why we use a lock file.
>
> The new backends allow multi-user access, but Gramps is not designed for this.  The database should not be corrupted, but data may be lost.  This is why locking is needs to be added.
>
> I suggest the following:
>
> 1. Add lock file support to the dbapi backends.
> 2. Move the posgresql backend into third-party addons.
> 3. Enable sqlite for all users and recommend it for multi-machine access.
>
> We can consider adding support for server-based databases and multi-user access in a future release.

That sounds like a good plan. Recalling that Doug’s original motivation for DBAPI was to get SQLite3’s file format stability (compared to Berkeley DB’s change of format at every major release) I think we might recommend SQLite3 for all users.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel