Gramps › GRAMPS - Dev

Gramps 5.0 GUI sync proposal

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

DS Blank

Gramps 5.0 GUI sync proposal

Devs,

One item that Enno brought up in his initial experimentation was the lack of GUI sync between two simultaneous users. For example, one might expect that if more than one user was using the same family tree, and one deleted a person, that the other Gtk instances would reflect that change (eg, the person view would update with the person removed).

Gramps has a very nice signal system implemented to take care of this for one user. It would not be too difficult to extend this system to allow it to work for many users.

There are some ideas about making such a system based on events (eg, when a delete is made). However, those are not general to all kinds of database.

Here is a proposal based on polling a new table:

* we would have another table in the database, called something like Signal

* whenever an object is edited/deleted/added, the signal is recorded in the table (including the time, signal, args and a unique ID for the instance)

* a background process on the other Gtk instances would poll this table. If new entries were made by other instances, then those signals would be replicated on the remote GUI

This update checker would run every n seconds (on the order of 1 to 5 seconds) looking to see if there were any signals to emit locally. We might only want to run this checker if a flag is given (eg, --sync).

I have a prototype worked up with the basic issues identified. Notes and questions:

* requires a new table (eg, Signal)

* requires some new code (make sure no db process could be interrupted)

* should we include this in Gramps 5.0?

* should it be optional (only when --sync flag is given)?

* what is a good number of seconds between polling (1, 5, 10 seconds)?

Or perhaps this is just not worth worrying about?

-Doug

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

manzi.sam

Re: Gramps 5.0 GUI sync proposal

CONTENTS DELETED

The author has deleted this message.

DS Blank

Re: Gramps 5.0 GUI sync proposal

On Fri, May 6, 2016 at 9:24 PM, Sam Manzi <[hidden email]> wrote:

On 7 May 2016 at 10:27, Doug Blank <[hidden email]> wrote:
Or perhaps this is just not worth worrying about?

Doug,

Yes this would be a great addition. +1

A solution needing to update a db on receiving a signal has many potential places of problems: updating a db in the middle of a some other db function, attempt to update gui at inappropriate time, etc. But, it is worth trying to see how it could work.

I've made a prototype here:

https://github.com/gramps-project/gramps/commits/gui-sync

(Warning, this branch will add a new table to your tree database.)

However, ran into a roadblock: with our current signals, it is impossible to tell where the signal came from. In the prototype, if Gramps instance 1 makes a change, it will correctly signal Gramps instance 2 and the remote GUI will refresh. However, when Gramps instance 2 emits the change, it will send it back to Gramps instance 1, where it will update the GUI, and further emit the change. This loop will continue forever.

To prevent this from happening, Gramps needs to know from where the signal originated. If it started with the current instance, then send it to the remotes. However, if the signal didn't start with the current instance, then it does not need to be repeated.

I can't think of a better solution than to add something to the signaling system so that it will be able to detect this situation. Any other ideas appreciated. Otherwise, we'll have to alter the signals somehow.

-Doug

-
Sam

3658: open other database in a new window
https://gramps-project.org/bugs/view.php?id=3658

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

enno

Re: Gramps 5.0 GUI sync proposal

Devs,

On Fri, May 6, 2016 at 9:24 PM, Sam Manzi <[hidden email]> wrote:

On 7 May 2016 at 10:27, Doug Blank <[hidden email]> wrote:

Or perhaps this is just not worth worrying about?

Doug,

Yes this would be a great addition. +1

A solution needing to update a db on receiving a signal has many potential places of problems: updating a db in the middle of a some other db function, attempt to update gui at inappropriate time, etc. But, it is worth trying to see how it could work.

I've made a prototype here:

https://github.com/gramps-project/gramps/commits/gui-sync

(Warning, this branch will add a new table to your tree database.)

However, ran into a roadblock: with our current signals, it is impossible to tell where the signal came from. In the prototype, if Gramps instance 1 makes a change, it will correctly signal Gramps instance 2 and the remote GUI will refresh. However, when Gramps instance 2 emits the change, it will send it back to Gramps instance 1, where it will update the GUI, and further emit the change. This loop will continue forever.

To prevent this from happening, Gramps needs to know from where the signal originated. If it started with the current instance, then send it to the remotes. However, if the signal didn't start with the current instance, then it does not need to be repeated.

I can't think of a better solution than to add something to the signaling system so that it will be able to detect this situation. Any other ideas appreciated. Otherwise, we'll have to alter the signals somehow.

I did some further reading on the subject, and found that the sqlite3 update hook only works within the context of a process, so it will never work between different instances of Gramps, let alone between a database tool and Gramps, which would be my way of working.

To prevent loops with signals in a table, the obvious hack would be to add a sending process ID to each signal, so that any database client can detect who sent it. There is another problem with this mechanism though, and that's when you have more than 2 instances. In that case, you have 1 signal sender, and an unknown number of receivers, and without further tricks, there is no way to find out when a signal can be removed, so I think that a table based solution is out of the question.

A standard solution for this would be a message passing mechanism based on a publish-subscribe pattern, using a message broker. I have worked with these things for years, but right now, I think they're beyond what's reasonable in Gramps. It's how our list works, but it doesn't solve the problem that I would have when I hack the database with SQLiteman or another tool.

This tells me that Gramps connect is still the best solution for multi-user operations, and that I can better hack my tree when Gramps is not running.

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Gerald Britton-2

Re: Gramps 5.0 GUI sync proposal

This is a problem facing all dbs. Row versioning is one solution in use. Basic idea is add a version column to each table. Each row gets a new version with every update. When updating a row, add the version to the where clause then check rows updated count. If not as expected, one or more rows has changed since retrieval. That signals a GUI refresh and an info message.

On Sat, May 7, 2016, 5:23 PM Enno Borgsteede <[hidden email]> wrote:

Devs,

On Fri, May 6, 2016 at 9:24 PM, Sam Manzi <[hidden email]> wrote:

On 7 May 2016 at 10:27, Doug Blank <[hidden email]> wrote:

Or perhaps this is just not worth worrying about?

Doug,

Yes this would be a great addition. +1

A solution needing to update a db on receiving a signal has many potential places of problems: updating a db in the middle of a some other db function, attempt to update gui at inappropriate time, etc. But, it is worth trying to see how it could work.

I've made a prototype here:

https://github.com/gramps-project/gramps/commits/gui-sync

(Warning, this branch will add a new table to your tree database.)

However, ran into a roadblock: with our current signals, it is impossible to tell where the signal came from. In the prototype, if Gramps instance 1 makes a change, it will correctly signal Gramps instance 2 and the remote GUI will refresh. However, when Gramps instance 2 emits the change, it will send it back to Gramps instance 1, where it will update the GUI, and further emit the change. This loop will continue forever.

To prevent this from happening, Gramps needs to know from where the signal originated. If it started with the current instance, then send it to the remotes. However, if the signal didn't start with the current instance, then it does not need to be repeated.

I can't think of a better solution than to add something to the signaling system so that it will be able to detect this situation. Any other ideas appreciated. Otherwise, we'll have to alter the signals somehow.

I did some further reading on the subject, and found that the sqlite3 update hook only works within the context of a process, so it will never work between different instances of Gramps, let alone between a database tool and Gramps, which would be my way of working.

To prevent loops with signals in a table, the obvious hack would be to add a sending process ID to each signal, so that any database client can detect who sent it. There is another problem with this mechanism though, and that's when you have more than 2 instances. In that case, you have 1 signal sender, and an unknown number of receivers, and without further tricks, there is no way to find out when a signal can be removed, so I think that a table based solution is out of the question.

A standard solution for this would be a message passing mechanism based on a publish-subscribe pattern, using a message broker. I have worked with these things for years, but right now, I think they're beyond what's reasonable in Gramps. It's how our list works, but it doesn't solve the problem that I would have when I hack the database with SQLiteman or another tool.

This tells me that Gramps connect is still the best solution for multi-user operations, and that I can better hack my tree when Gramps is not running.

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

enno

Re: Gramps 5.0 GUI sync proposal

Gerald,
>
> This is a problem facing all dbs. Row versioning is one solution in
> use. Basic idea is add a version column to each table. Each row gets a
> new version with every update. When updating a row, add the version to
> the where clause then check rows updated count. If not as expected,
> one or more rows has changed since retrieval. That signals a GUI
> refresh and an info message.
>
Interesting thought, but how do you deal with deletes and inserts?

cheers,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

DS Blank

Re: Gramps 5.0 GUI sync proposal

In reply to this post by enno

On Sat, May 7, 2016 at 5:23 PM, Enno Borgsteede <[hidden email]> wrote:

Devs,

On Fri, May 6, 2016 at 9:24 PM, Sam Manzi <[hidden email]> wrote:

On 7 May 2016 at 10:27, Doug Blank <[hidden email][hidden email]> wrote:

Or perhaps this is just not worth worrying about?

Doug,

Yes this would be a great addition. +1

A solution needing to update a db on receiving a signal has many potential places of problems: updating a db in the middle of a some other db function, attempt to update gui at inappropriate time, etc. But, it is worth trying to see how it could work.

I've made a prototype here:

https://github.com/gramps-project/gramps/commits/gui-sync

(Warning, this branch will add a new table to your tree database.)

However, ran into a roadblock: with our current signals, it is impossible to tell where the signal came from. In the prototype, if Gramps instance 1 makes a change, it will correctly signal Gramps instance 2 and the remote GUI will refresh. However, when Gramps instance 2 emits the change, it will send it back to Gramps instance 1, where it will update the GUI, and further emit the change. This loop will continue forever.

To prevent this from happening, Gramps needs to know from where the signal originated. If it started with the current instance, then send it to the remotes. However, if the signal didn't start with the current instance, then it does not need to be repeated.

I can't think of a better solution than to add something to the signaling system so that it will be able to detect this situation. Any other ideas appreciated. Otherwise, we'll have to alter the signals somehow.

I did some further reading on the subject, and found that the sqlite3 update hook only works within the context of a process, so it will never work between different instances of Gramps, let alone between a database tool and Gramps, which would be my way of working.

That explains why I couldn't get it to work.

To prevent loops with signals in a table, the obvious hack would be to add a sending process ID to each signal, so that any database client can detect who sent it. There is another problem with this mechanism though, and that's when you have more than 2 instances. In that case, you have 1 signal sender, and an unknown number of receivers, and without further tricks, there is no way to find out when a signal can be removed, so I think that a table based solution is out of the question.

I don't think that problem is unsurmountable. These signals are only useful now, in real time. The prototype has a timestamp on the signal message, but a real solution would probably just provide an id, and remember which have already been emitted locally.

A standard solution for this would be a message passing mechanism based on a publish-subscribe pattern, using a message broker. I have worked with these things for years, but right now, I think they're beyond what's reasonable in Gramps. It's how our list works, but it doesn't solve the problem that I would have when I hack the database with SQLiteman or another tool.

Having a system that would automatically work outside of Gramps was a bigger scope than what I imagined. But one could simple add a message in the signal table to refresh everything (or a specific type) when finished, if you wanted to update all of the remote views.

This tells me that Gramps connect is still the best solution for multi-user operations, and that I can better hack my tree when Gramps is not running.

Maybe. I think the prototype could be refined to at least take care of the basic function of syncing Gtk Gramps instances. But, the things to overcome are being able to update the database and GUI when we haven't expected such updates before. I played around with the gui-sync branch, and had both the GUI and database lock up. Such a feature will require some careful analysis and further exploration. I don't think it will be a quick fix for Gramps 5.0.

-Doug

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Nick Hall

Re: Gramps 5.0 GUI sync proposal

In reply to this post by Gerald Britton-2

On 08/05/16 04:50, Gerald Britton wrote:
> This is a problem facing all dbs. Row versioning is one solution in
> use. Basic idea is add a version column to each table. Each row gets a
> new version with every update. When updating a row, add the version to
> the where clause then check rows updated count. If not as expected,
> one or more rows has changed since retrieval. That signals a GUI
> refresh and an info message.

Yes.

We should also consider application level object locking. Suppose an
instance edits a person using the person editor. It takes a copy, then
another instance edits the same person. It also takes a copy of the
original. Whichever edit finishes first will write the object and
update the version and/or timestamp. When the second edit finishes it
will detect that an update has been made since the start of the edit,
but the user will not necessarily know what to do.

It may be better to warn the user that the object is already being
edited when they start their edit, rather when they write the object.

Nick.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

DS Blank

Re: Gramps 5.0 GUI sync proposal

On Sun, May 8, 2016 at 10:13 AM, Nick Hall <[hidden email]> wrote:

On 08/05/16 04:50, Gerald Britton wrote:
> This is a problem facing all dbs. Row versioning is one solution in
> use. Basic idea is add a version column to each table. Each row gets a
> new version with every update. When updating a row, add the version to
> the where clause then check rows updated count. If not as expected,
> one or more rows has changed since retrieval. That signals a GUI
> refresh and an info message.

Yes.

We should also consider application level object locking. Suppose an
instance edits a person using the person editor. It takes a copy, then
another instance edits the same person. It also takes a copy of the
original. Whichever edit finishes first will write the object and
update the version and/or timestamp. When the second edit finishes it
will detect that an update has been made since the start of the edit,
but the user will not necessarily know what to do.

It may be better to warn the user that the object is already being
edited when they start their edit, rather when they write the object.

That is a good idea.

On a related note, it would be nice to separate in the GUI the notion of opening up the details of an object to view, versus planning on editing. For example, currently when you just want to see the details of a person, you have to open the data in an "editor". Clicking "Ok" will update the data (and the last changed time, regardless of whether any change was made).

Rather, it would be nice to see the data, but have a secondary button in the edit dialog to allow editing. By clicking an "Edit" button, the system could "lock the row" (via some mechanism) which would be reflected in the database, and make the fields in the dialog editable. We could even then allow some users to view, but not edit (eg, the Edit button would be disabled).

At least sqlite does not have row-locking functionality, and maybe others don't as well. Perhaps a "locked" field, and a timestamp (for timeout) would allow such functionality? We'd also have to perhaps "lock" (or check for locks on) records before editing them (say, in a transaction), or fail and rollback if any were locked.

-Doug

Nick.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Nick Hall

Re: Gramps 5.0 GUI sync proposal

On 08/05/16 16:01, Doug Blank wrote:
> On a related note, it would be nice to separate in the GUI the notion
> of opening up the details of an object to view, versus planning on
> editing. For example, currently when you just want to see the details
> of a person, you have to open the data in an "editor". Clicking "Ok"
> will update the data (and the last changed time, regardless of whether
> any change was made).
>

I have been saying this for years. Use editors for editing and views
for viewing.

In my Gramps, I have replaced the relationship view with a series of
interconnected viewers. Each viewer displays information from multiple
tables.

Together with using forms for data entry, this means that I use the
standard editors far less often.

> Rather, it would be nice to see the data, but have a secondary button
> in the edit dialog to allow editing. By clicking an "Edit" button, the
> system could "lock the row" (via some mechanism) which would be
> reflected in the database, and make the fields in the dialog editable.
> We could even then allow some users to view, but not edit (eg, the
> Edit button would be disabled).

I would prefer to only use editors for editing.

In the past we have added features to the editors to make them better
viewers, not better editors.

>
> At least sqlite does not have row-locking functionality, and maybe
> others don't as well. Perhaps a "locked" field, and a timestamp (for
> timeout) would allow such functionality? We'd also have to perhaps
> "lock" (or check for locks on) records before editing them (say, in a
> transaction), or fail and rollback if any were locked.
>

A separate lock table would probably be better. It would only ever
contain a relatively small number of lock records.

Nick.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

enno

Re: Gramps 5.0 GUI sync proposal

Op 08-05-16 om 18:06 schreef Nick Hall:
>> At least sqlite does not have row-locking functionality, and maybe
>> others don't as well. Perhaps a "locked" field, and a timestamp (for
>> timeout) would allow such functionality? We'd also have to perhaps
>> "lock" (or check for locks on) records before editing them (say, in a
>> transaction), or fail and rollback if any were locked.
>>
> A separate lock table would probably be better. It would only ever
> contain a relatively small number of lock records.
I agree. We may need to add a user@node and/or PID in that.

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Gerald Britton-2

Re: Gramps 5.0 GUI sync proposal

Actually I'd argue we should leverage the RDBMS's built-in locking. Already battle-hardened. Thread safe, etc

We'll need an adapter for each one, and well-written transactions and stored procs, but I think that's a good thing.

On Sun, May 8, 2016 at 1:56 PM, Enno Borgsteede <[hidden email]> wrote:

Op 08-05-16 om 18:06 schreef Nick Hall:
>> At least sqlite does not have row-locking functionality, and maybe
>> others don't as well. Perhaps a "locked" field, and a timestamp (for
>> timeout) would allow such functionality? We'd also have to perhaps
>> "lock" (or check for locks on) records before editing them (say, in a
>> transaction), or fail and rollback if any were locked.
>>
> A separate lock table would probably be better. It would only ever
> contain a relatively small number of lock records.
I agree. We may need to add a user@node and/or PID in that.

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Gerald Britton, MCSE-DP, MVP
LinkedIn Profile: http://ca.linkedin.com/in/geraldbritton

enno

Re: Gramps 5.0 GUI sync proposal

Op 8-5-2016 om 20:08 schreef Gerald Britton:

Actually I'd argue we should leverage the RDBMS's built-in locking. Already battle-hardened. Thread safe, etc

We'll need an adapter for each one, and well-written transactions and stored procs, but I think that's a good thing.

This assumes the presence of an RDBMS with such features, and SQLite is not such a thing.

regards,

Enno

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Gerald Britton-2

Re: Gramps 5.0 GUI sync proposal

Well, SQLite is "lite" for a reason. I'm not SQLite expert (far, far from it) yet it is ACID compliant which makes it equivalent in the most import aspects to a fully-fledged RDBMS. e.g.

"SQLite implements serializable transactions that are atomic, consistent, isolated, and durable, even if the transaction is interrupted by a program crash, an operating system crash, or a power failure to the computer."

https://www.sqlite.org/transactional.html

so we can and should leverage this power. It does not support stored procedures, which is a pity but not a real problem. That just means more client-side (i.e. Gramps) code. It *does* support transactions though so we really do have a good foundation.

On Sun, May 8, 2016 at 2:52 PM, Enno Borgsteede <[hidden email]> wrote:

Op 8-5-2016 om 20:08 schreef Gerald Britton:

Actually I'd argue we should leverage the RDBMS's built-in locking. Already battle-hardened. Thread safe, etc

We'll need an adapter for each one, and well-written transactions and stored procs, but I think that's a good thing.

This assumes the presence of an RDBMS with such features, and SQLite is not such a thing.

regards,

Enno

Gerald Britton, MCSE-DP, MVP
LinkedIn Profile: http://ca.linkedin.com/in/geraldbritton

DS Blank

Re: Gramps 5.0 GUI sync proposal

Good ideas in this thread. FYI, I've started "GEPS 042: Multi-user record locking and editing" to keep track of these related ideas:

https://gramps-project.org/wiki/index.php?title=GEPS_042:_Multi-user_record_locking_and_editing

-Doug

On Sun, May 8, 2016 at 3:50 PM, Gerald Britton <[hidden email]> wrote:

Well, SQLite is "lite" for a reason. I'm not SQLite expert (far, far from it) yet it is ACID compliant which makes it equivalent in the most import aspects to a fully-fledged RDBMS. e.g.

"SQLite implements serializable transactions that are atomic, consistent, isolated, and durable, even if the transaction is interrupted by a program crash, an operating system crash, or a power failure to the computer."
https://www.sqlite.org/transactional.html

so we can and should leverage this power. It does not support stored procedures, which is a pity but not a real problem. That just means more client-side (i.e. Gramps) code. It *does* support transactions though so we really do have a good foundation.

On Sun, May 8, 2016 at 2:52 PM, Enno Borgsteede <[hidden email]> wrote:

Op 8-5-2016 om 20:08 schreef Gerald Britton:

Actually I'd argue we should leverage the RDBMS's built-in locking. Already battle-hardened. Thread safe, etc

We'll need an adapter for each one, and well-written transactions and stored procs, but I think that's a good thing.

This assumes the presence of an RDBMS with such features, and SQLite is not such a thing.

regards,

Enno

--
Gerald Britton, MCSE-DP, MVP
LinkedIn Profile: http://ca.linkedin.com/in/geraldbritton

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel