Gramps 5.0.0-alpha2 released

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Gramps 5.0.0-alpha2 released

Josip
The Gramps team releases version v5.0.0-alpha2, an experimental pre-release.

You can get Gramps 5.0.0-alpha2 from the GitHub page.
https://github.com/gramps-project/gramps/releases

Think on backup before upgrade!

Thank you all!

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

John Ralls-2

> On Jun 10, 2017, at 12:51 PM, Josip <[hidden email]> wrote:
>
> The Gramps team releases version v5.0.0-alpha2, an experimental pre-release.
>
> You can get Gramps 5.0.0-alpha2 from the GitHub page.
> https://github.com/gramps-project/gramps/releases
>
> Think on backup before upgrade!
>

The Mac bundle will be delayed, it crashes on startup because of a problem deep in gobject-introspection.

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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

Paul Franklin-5
In reply to this post by Josip
> The Gramps team releases version v5.0.0-alpha2, an experimental
> pre-release.

> Think on backup before upgrade!

The key word is "experimental"!

It might be unwise to "upgrade" your main/real gramps
family tree into 5.0.0-alpha2.  In general, we recommend
you make a copy of your family tree instead (typically by
doing a "gramps XML" export), then try 5.0.0-alpha2 on
the copy.  (You can keep things really separate by using
the GRAMPSHOME environmental variable, if you want.)

It's been about a year since 5.0.0-alpha1 was released
so we are interested in your feedback, especially if you
discover any bugs or problems which we haven't noticed.

https://gramps-project.org/wiki/index.php?title=Using_the_bug_tracker

Please file a bug report (selecting the "5.0.0-alpha2"
version) if you find one.  We want testers for alpha2,
but only if you are sophisticated and resilient enough
to know how to keep it away from your real data.

Once the Windows and Debian and Mac bundles are
released, of course.  8-)

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

Thomas Guyot-Sionnest
In reply to this post by Josip
On 10/06/17 03:51 PM, Josip wrote:

> The Gramps team releases version v5.0.0-alpha2, an experimental
> pre-release.
>
> You can get Gramps 5.0.0-alpha2 from the GitHub page.
> https://github.com/gramps-project/gramps/releases
>
> Think on backup before upgrade!
>
> Thank you all!
>
Nice... I plan on testing it with an external MariaDB (InnoDB)
database... Out of curiosity will it work fine with multiple users
connecting on the same database at the same time? I'm not too much
concerned about the possible issue of having two users try to change the
same object, which should fail if transactions are used. (From
experience the two most likely source of issues would be long-running
transactions and local caching of data... if data is read every time and
change are committed instantly then it should work fine...)

Are there any plans for Debian binaries (like in aplha1)? I can install
from sources, but using the packages is easier...

Also I'd need the MadiaDB* bindings in Windows... I remember someone
asked for the PostgreSQL ones on the archives, they had to be compiled
specifically for the Python interpreter used by Gramps. Considering that
5.0 supports external databases I think the bindings for supported
backends should be included.

*MySQL and MariaDB APIs are mostly 100% compatible, but I cannot seem to
connect using "browser-style" trusted SSL certs using the MySQL library
in Linux... I can preload the MariaDB library to make it work and the
next Debian release will be compiled against the MariaDB version... In
Windows I guess it should use whatever library is installed (MariaDB or
MySQL), is that assumption correct? I know I can connect with MariaDB
libraries but I haven't tested MySQL.

Regards,

--
Thomas



------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

Paul Franklin-5
On 6/12/17, Paul Franklin <[hidden email]> wrote:
>> Are there any plans for Debian binaries (like in aplha1)? I can install
>> from sources, but using the packages is easier...
>
> It's coming.  Please be patient.  We are all volunteers.

The Debian 5.0.0-alpha2 is now on
https://github.com/gramps-project/gramps/releases

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

prculley
In reply to this post by Thomas Guyot-Sionnest
 
Out of curiosity will it work fine with multiple users connecting on the same
database at the same time? I'm not too much
concerned about the possible issue of having two users try to change the
same object, which should fail if transactions are used. (From
experience the two most likely source of issues would be long-running
transactions and local caching of data... if data is read every time and
change are committed instantly then it should work fine...)

Don't get your hopes up.  Gramps was written as a single user application.  While we have what we call 'transactions', they are NOT what a db person considers a transaction.  Instead they are a grouping of related commits managed together by the application.  They support undo/redo and the only thing we guarantee is that the db is consistent before and after the transaction.  It may not be consistent in the middle (consistent meaning that various references to other objects are correct).

In particular, I'm pretty sure that there is no 'locking' of the db during the transaction, at any level.  There was a long thread among the developers a while back where potential mechanisms for that were discussed, but as far as I know, nothing was coded.

So multiple users are certain to cause trouble if they ever work in the same regions of the db.  And there is a lot of 'local caching of data' involved in the GUI and object editors.  We depend on the editors to manage the consistency, they DON'T 'read the data every time  and commit instantly', and if you look hard you can find cases where this is not handled well between various GUI elements even now.

Fair warning...
Paul C.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: Gramps 5.0.0-alpha2 released

Thomas Guyot-Sionnest
On 13/06/17 08:59 AM, Paul Culley wrote:
 
Out of curiosity will it work fine with multiple users connecting on the same
database at the same time? I'm not too much
concerned about the possible issue of having two users try to change the
same object, which should fail if transactions are used. (From
experience the two most likely source of issues would be long-running
transactions and local caching of data... if data is read every time and
change are committed instantly then it should work fine...)

Don't get your hopes up.  Gramps was written as a single user application.  While we have what we call 'transactions', they are NOT what a db person considers a transaction.  Instead they are a grouping of related commits managed together by the application.  They support undo/redo and the only thing we guarantee is that the db is consistent before and after the transaction.  It may not be consistent in the middle (consistent meaning that various references to other objects are correct).

In particular, I'm pretty sure that there is no 'locking' of the db during the transaction, at any level.  There was a long thread among the developers a while back where potential mechanisms for that were discussed, but as far as I know, nothing was coded.

So multiple users are certain to cause trouble if they ever work in the same regions of the db.  And there is a lot of 'local caching of data' involved in the GUI and object editors.  We depend on the editors to manage the consistency, they DON'T 'read the data every time  and commit instantly', and if you look hard you can find cases where this is not handled well between various GUI elements even now.

Thanks, although what you describe is a pretty safe behavior with regard to the DB. Additional safety may be provided by changing the default transaction isolation level (I'm just reading about PostgreSQL now... it appears the default is Read Comitted while MySQL's default is Repeatable Read) - see https://www.postgresql.org/docs/9.1/static/transaction-iso.html

If two transactions try to change the same rows one will be locked until the other completes, and if a deadlock occurs (both tx waiting for each others) one will be rolled back and the client will get an error. That could happen, and in a perfect world gramps should check the the data it's trying to change hasn't been modified by someone else and then retry the transaction. I assume that will not be the case, but if each edit is done as a single transaction then at the very least the possible loss is limited to a single edit.

With the default isolation level of PostgreSQL I don't think this could even happen unless two tx change the same rows in parallel (previously read rows will not be taken into account), OTOH there will be no warning if the same field gets changed consecutively by two users if one commits before the other starts updating (the latter will blindly overwrite the former).

The other issue can be caching. If Gramps doesn't read data from the database every time then it is hard to see what others have done just before you. In alpha-1 caching was not an issue, though you may have to switch between objects to refresh data (there may be a need for a refresh function...)

Oh, last but not least, I haven't yet checked if this was fixed in alpha-2 (since MySQL support was dropped I need to setup PostgreSQL instead...) but Gramps should attempt to reconnect if the connection dies (if it happens during a transaction the tx should be assumed to have been rolled back*)

(*) A configuration option in MySQL changed default setting a few years back to rollback only the timeout statement, not full tx... In PostgreSQL it appears it rolls back the the full tx which is the safe behavior (based on user comments; I haven't yet found an explicit statement about this in Postgres documentation). This is only for TCP timeouts during a statement, not deadlocks/timeouts that leaves the connection open. When in doubt the safe thing to do is to rollback and try again.

Regards,
-- 
Thomas

------------------------------------------------------------------------------
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
Loading...