Proposed feature requests for Reorder Gramps ID plugin.

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

Proposed feature requests for Reorder Gramps ID plugin.

sturdy
Hi List,

Just looking for comments of others concerning the reformatting and
reordering (resequencing?) of Gramps IDs. I would like to use the Gramps
ID (at least for Sources) to help me identify reference materials that I
maintain in a local library database. For example a book I have is given
a Gramps Source Id of Snnnn and I enter that same ID in my database of
books to help identify the link to Gramps. But I am afraid to do this
because the Reorder plugin seems to have the potential to change the
number sequence. I would like to propose a couple of simple modifications:

First, it looks to me that the purpose of the Reorder Gramps Id plugin
is really to reformat to the formatting scheme coded in Preferences > ID
Formats. It seems a scary misnomer so I suggest the plugin be renamed to
Reformat Gramps ID and wiki, etc. be changed accordingly.

Second, develop a scheme that precludes a Gramps ID from being changed.
A couple of possibilities come to mind:

a. With the default formatting scheme, the first position of the Gramps
ID identifies the object type, for example, Snnnn for Source. I suggest
that when the default first letter is changed by the user, that Gramps
ID should NOT be changed. More generally, skip reformatting when the ID
does not follow the expected letter/number (Xn) format in Preferences.

b. Provide a "No Change" button next to the Gramps ID of each editor.

c. A more global solution is to provide a button or another code in the
Preferences editor, for example, *S%04D, where the * would prevent
reformatting or resequencing.

Option a is my favorite because it is simple to code and allows me to
choose which IDs I want to preserve. Also probably best for users using
Gramps ID for other local purposes.

Comments?

Bob S.


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

sturdy
Hi Dave,

Thanks for the comments, see inline.

Maybe I'm not understanding your need, but why don't you link your sources through a common repository. When you link the source to the repository, you can give it your own special call number.
Yes, that would work but involves manually creating and recording another number/ID and is unnecessary when the Gramps ID is such a handy identifier.

I used the Gramps ID a couple of years ago when identifying and filling Places and lat/lon locations and there have been other uses mentioned on the list in the past. It is a little scary that the Gramps ID should be for the use of Gramps Users but then subject to change by other utilities. It keeps us from using the ID for anything important.
The one time I used the re-order function for ID's all it did was standardized the length with leading 0's.
Yes, usually the case. The user's manual doesn't say much except about reordering and I'm not sure what that means. I'm not a Python expert, but a look at the code indicates that the Gramps ID may be resequenced by the Reorder tool. One example is in the event of a dupe ID. Superficially, that sounds okay but can be dangerous and cause unexpected results for the user who may be counting on the unchanged ID.

I think we should be able to specify a Gramps ID as stated in the manual and not be concerned that it may eventually change.
Thanks again...

Regards,
Bob S.


------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

enno
Hi Bob,
Thanks for the comments, see inline.

Maybe I'm not understanding your need, but why don't you link your sources through a common repository. When you link the source to the repository, you can give it your own special call number.
Yes, that would work but involves manually creating and recording another number/ID and is unnecessary when the Gramps ID is such a handy identifier.
While it may look handy, it should not be considered a stable identifier. In the context of a single tree, Gramps IDs will normally not change by themselves, but they will be re-formatted when you import a backup file into a new empty tree, and they will be re-numbered when the target tree is not empty.

I used the Gramps ID a couple of years ago when identifying and filling Places and lat/lon locations and there have been other uses mentioned on the list in the past. It is a little scary that the Gramps ID should be for the use of Gramps Users but then subject to change by other utilities. It keeps us from using the ID for anything important.
That's right, and IMO the idea that the ID is for users is utter nonsense. These IDs are needed to make GEDCOM export and import work right, but there is absolutely no guarantee that they are preserved. The only guarantee that I can give is that they will change over time, any time when you import data into a non empty tree, and almost any time when you import data into another program, or an on-line tree for that matter. Many other programs simply use numbers internally, and only add a fixed leading character on export, which is immediately discarded on import again.

The one time I used the re-order function for ID's all it did was standardized the length with leading 0's.
Yes, usually the case. The user's manual doesn't say much except about reordering and I'm not sure what that means. I'm not a Python expert, but a look at the code indicates that the Gramps ID may be resequenced by the Reorder tool. One example is in the event of a dupe ID. Superficially, that sounds okay but can be dangerous and cause unexpected results for the user who may be counting on the unchanged ID.
In practical situations, users should never count on this type of ID being a stable reference, for the reasons mentioned above. IDs will probably be stable if you never merge trees, but they are absolutely unreliable between programs, even between different Gramps installations.


I think we should be able to specify a Gramps ID as stated in the manual and not be concerned that it may eventually change.
No. The idea of a stable Gramps ID is a silly fantasy. In reality, Gramps IDs don't even exist outside Gramps. Some are mapped to GEDCOM IDs, where they can be renumbered at will, and many are lost, because GEDCOM does not allow the use of IDs for citations, places, events, etc. The term itself is hence highly misleading, and should better be removed, because it suggests that it is recognized by the outside world, where in reality it is not.

True IDs like the ones used by libraries, or in the FamilySearch Family Tree, are way more complicated, and use a mechanism that guarantees uniqueness in a larger context than a single tree stored in a program like Gramps.

regards,

Enno


------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

sturdy

Hi Enno,

Thanks for your words of wisdom. So true, but it was a nice dream, anyway. It's a few extra steps but I'll go back to the call number. But it does seem like the Gramps ID could be made static as I described without hindering other features.

My best,

Bob S.


On 09/10/2016 03:12 PM, Enno Borgsteede wrote:
Hi Bob,
Thanks for the comments, see inline.

Maybe I'm not understanding your need, but why don't you link your sources through a common repository. When you link the source to the repository, you can give it your own special call number.
Yes, that would work but involves manually creating and recording another number/ID and is unnecessary when the Gramps ID is such a handy identifier.
While it may look handy, it should not be considered a stable identifier. In the context of a single tree, Gramps IDs will normally not change by themselves, but they will be re-formatted when you import a backup file into a new empty tree, and they will be re-numbered when the target tree is not empty.

I used the Gramps ID a couple of years ago when identifying and filling Places and lat/lon locations and there have been other uses mentioned on the list in the past. It is a little scary that the Gramps ID should be for the use of Gramps Users but then subject to change by other utilities. It keeps us from using the ID for anything important.
That's right, and IMO the idea that the ID is for users is utter nonsense. These IDs are needed to make GEDCOM export and import work right, but there is absolutely no guarantee that they are preserved. The only guarantee that I can give is that they will change over time, any time when you import data into a non empty tree, and almost any time when you import data into another program, or an on-line tree for that matter. Many other programs simply use numbers internally, and only add a fixed leading character on export, which is immediately discarded on import again.

The one time I used the re-order function for ID's all it did was standardized the length with leading 0's.
Yes, usually the case. The user's manual doesn't say much except about reordering and I'm not sure what that means. I'm not a Python expert, but a look at the code indicates that the Gramps ID may be resequenced by the Reorder tool. One example is in the event of a dupe ID. Superficially, that sounds okay but can be dangerous and cause unexpected results for the user who may be counting on the unchanged ID.
In practical situations, users should never count on this type of ID being a stable reference, for the reasons mentioned above. IDs will probably be stable if you never merge trees, but they are absolutely unreliable between programs, even between different Gramps installations.


I think we should be able to specify a Gramps ID as stated in the manual and not be concerned that it may eventually change.
No. The idea of a stable Gramps ID is a silly fantasy. In reality, Gramps IDs don't even exist outside Gramps. Some are mapped to GEDCOM IDs, where they can be renumbered at will, and many are lost, because GEDCOM does not allow the use of IDs for citations, places, events, etc. The term itself is hence highly misleading, and should better be removed, because it suggests that it is recognized by the outside world, where in reality it is not.

True IDs like the ones used by libraries, or in the FamilySearch Family Tree, are way more complicated, and use a mechanism that guarantees uniqueness in a larger context than a single tree stored in a program like Gramps.

regards,

Enno



------------------------------------------------------------------------------


_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users


------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Rich Lakey
Enno I find your words of wisdom is what I have read previously. However I have went through a number of Gramps releases and new system installs over the last 6 years without my ID's changing. I use a personal code in the ID's for both places and individuals.  But I have never imported one of my backups or merged another file. When I install a new linux system or a new Gramps I just copy the gramps database. Sometimes a new release of Gramps converts the data format such as 4.0.4 to 4.2.3 but that does not change the ID's. As I have been working hard to get my places hierarchical for the new system implemented with 4.1.3, I plan to do an import for the first time on my second computer to compare and find errors I have with my Hierarchy. It will be interesting to see what happens to my hard work with my ID's and titles. If they are destroyed I may stop using export for a backup and just backup a full copy of my DB.
Rich 

On 09/10/2016 02:40 PM, [hidden email] wrote:

Hi Enno,

Thanks for your words of wisdom. So true, but it was a nice dream, anyway. It's a few extra steps but I'll go back to the call number. But it does seem like the Gramps ID could be made static as I described without hindering other features.

My best,

Bob S.


On 09/10/2016 03:12 PM, Enno Borgsteede wrote:
Hi Bob,
Thanks for the comments, see inline.

Maybe I'm not understanding your need, but why don't you link your sources through a common repository. When you link the source to the repository, you can give it your own special call number.
Yes, that would work but involves manually creating and recording another number/ID and is unnecessary when the Gramps ID is such a handy identifier.
While it may look handy, it should not be considered a stable identifier. In the context of a single tree, Gramps IDs will normally not change by themselves, but they will be re-formatted when you import a backup file into a new empty tree, and they will be re-numbered when the target tree is not empty.

I used the Gramps ID a couple of years ago when identifying and filling Places and lat/lon locations and there have been other uses mentioned on the list in the past. It is a little scary that the Gramps ID should be for the use of Gramps Users but then subject to change by other utilities. It keeps us from using the ID for anything important.
That's right, and IMO the idea that the ID is for users is utter nonsense. These IDs are needed to make GEDCOM export and import work right, but there is absolutely no guarantee that they are preserved. The only guarantee that I can give is that they will change over time, any time when you import data into a non empty tree, and almost any time when you import data into another program, or an on-line tree for that matter. Many other programs simply use numbers internally, and only add a fixed leading character on export, which is immediately discarded on import again.

The one time I used the re-order function for ID's all it did was standardized the length with leading 0's.
Yes, usually the case. The user's manual doesn't say much except about reordering and I'm not sure what that means. I'm not a Python expert, but a look at the code indicates that the Gramps ID may be resequenced by the Reorder tool. One example is in the event of a dupe ID. Superficially, that sounds okay but can be dangerous and cause unexpected results for the user who may be counting on the unchanged ID.
In practical situations, users should never count on this type of ID being a stable reference, for the reasons mentioned above. IDs will probably be stable if you never merge trees, but they are absolutely unreliable between programs, even between different Gramps installations.


I think we should be able to specify a Gramps ID as stated in the manual and not be concerned that it may eventually change.
No. The idea of a stable Gramps ID is a silly fantasy. In reality, Gramps IDs don't even exist outside Gramps. Some are mapped to GEDCOM IDs, where they can be renumbered at will, and many are lost, because GEDCOM does not allow the use of IDs for citations, places, events, etc. The term itself is hence highly misleading, and should better be removed, because it suggests that it is recognized by the outside world, where in reality it is not.

True IDs like the ones used by libraries, or in the FamilySearch Family Tree, are way more complicated, and use a mechanism that guarantees uniqueness in a larger context than a single tree stored in a program like Gramps.

regards,

Enno



------------------------------------------------------------------------------


_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users



------------------------------------------------------------------------------


_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users



------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

enno
In reply to this post by sturdy
Hi Bob,

> Thanks for your words of wisdom. So true, but it was a nice dream,
> anyway. It's a few extra steps but I'll go back to the call number.
> But it does seem like the Gramps ID could be made static as I
> described without hindering other features.
I understand what you mean, but I also see a conflict of interest. Where
you suggested that the reorder (or reformat) command should leave non
standard IDs alone, i.e. ones that don't start with the designated
character, my wish would be the exact opposite.

I don't use the reorder tool very often, but I do use it when I import
an Ancestry tree. And that's because the Ancestry site exports person
IDs like P1 instead of the more common I1 or I0001, and source IDs like
S-524703423. When I merge such a tree into the main one, I use the
reorder tool to make sure that all person IDs look the same and source
IDs too. I may import the Ancestry tree into an empty one first, reorder
that, and then select what data to export to .gramps format, and import
into the main one. With such an approach, I can avoid having reorder
things that don't really need reordering.

Because IDs need to be unique on export, we need a way to make sure that
they are, and letting all IDs follow the same type dependent numbering
scheme is a simple way to achieve that. There are other ways however,
and there's no part in the GEDCOM spec that says that IDs must start
with an alphabetic character, nor that that character should be followed
by a number. The only thing that the spec demands is that IDs are
unique, and that they're no longer than 20 characters.

In practical situations, I have found that IDs are quite static, meaning
that existing IDs don't change, unless you use the reorder tool, or
merge your tree into another one. In other words, if you don't merge or
reorder, your source IDs will match the IDs in your own source table for
a very long time.

I have also found that when you import a Gramps backup into an empty
tree, and the only difference between configured formats is the number
of digits, there is no change in the numerical ID value either. With
that I mean that when I forget to change the person ID format to I%05d
when I set up Gramps on a new PC, the only difference that I see is that
person 1 has ID I0001 instead of I00001. The numerical value itself is
never changed.

All in all, I think that if you stick to a single tree in Gramps, and
don't merge or reorder, you can sort of rely on your source IDs, or any
other one for that matter. You can not rely on IDs to be preserved when
transferred to other software however.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

sturdy

Hi Enno,

I understand what you mean, but I also see a conflict of interest. Where you suggested that the reorder (or reformat) command should leave non standard IDs alone, i.e. ones that don't start with the designated character, my wish would be the exact opposite.

Either method works for me. My suggestion was only a simple option. My thought was that any change in the default pattern must mean that the user has purposely changed the ID so it should not be touched by Gramps. Seems logical to me, sigh.
I don't use the reorder tool very often, but I do use it when I import an Ancestry tree.
+1. I'm always very cautious of tools because there is so little documentation. There are a couple I remove from the menu after a bad experience. Reorder is probably next.

All in all, I think that if you stick to a single tree in Gramps, and don't merge or reorder, you can sort of rely on your source IDs, or any other one for that matter. You can not rely on IDs to be preserved when transferred to other software however.

My conclusions, too. I'm giving it a try by copying the Source ID into the Call Number field then I'll use the ID as my link to my library. I'll be able to look at the Call Number to see If anything has gone wrong,

In case you're curious, the reason for this exercise is that for each source book from my local digital library, I created a symlink and renamed it to the Source ID, and place it into the Gramphs media path to link to my reference library of 600+ digital books (pdf mostly; storage is cheap these days). Unfortunately, the link editors in Gramps still have issues (bug 9551). It works well as long as the ID doesn't change.

My best,
Bob S.

------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Ron Johnson
In reply to this post by enno
On 09/11/2016 02:58 PM, [hidden email] wrote:
[snip]

All in all, I think that if you stick to a single tree in Gramps, and don't merge or reorder, you can sort of rely on your source IDs, or any other one for that matter. You can not rely on IDs to be preserved when transferred to other software however.

My conclusions, too. I'm giving it a try by copying the Source ID into the Call Number field then I'll use the ID as my link to my library. I'll be able to look at the Call Number to see If anything has gone wrong,

In case you're curious, the reason for this exercise is that for each source book from my local digital library, I created a symlink and renamed it to the Source ID, and place it into the Gramphs media path to link to my reference library of 600+ digital books (pdf mostly; storage is cheap these days). Unfortunately, the link editors in Gramps still have issues (bug 9551). It works well as long as the ID doesn't change.

Compute the CRC32 value (even better would be CRC64) of the file and use that as the Call Number.  That's sure to be less volatile than a gramps ID, and while big enough to minimize collisions, is still much smaller than md5 hashes.

-- 
World Peace Through Nuclear Pacification

------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

sturdy
Hi Ron,
Compute the CRC32 value (even better would be CRC64) of the file and use that as the Call Number.  That's sure to be less volatile than a gramps ID, and while big enough to minimize collisions, is still much smaller than md5 hashes.
Good idea but I'm old and tired. Does Gramps have tool for that? ;-)

Actually, as you implied, almost anything will work. Even the title. I like the Gramps ID because it is short and available, almost unique and provides a quick visual to the library manager table.

Regards,
Bob S.



------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Ron Johnson
In reply to this post by Ron Johnson
On 09/11/2016 03:50 PM, [hidden email] wrote:
Hi Ron,
Compute the CRC32 value (even better would be CRC64) of the file and use that as the Call Number.  That's sure to be less volatile than a gramps ID, and while big enough to minimize collisions, is still much smaller than md5 hashes.
Good idea but I'm old and tired. Does Gramps have tool for that? ;-)

The CLI makes it much easier than a gramps tool.

$ cd your/library/folder
$ crc32 *.pdf

Actually, as you implied, almost anything will work. Even the title. I like the Gramps ID because it is short and available, almost unique and provides a quick visual to the library manager table.

Which is why I thought of crc32.

-- 
World Peace Through Nuclear Pacification

------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

sturdy
Hi Ron,

I must admit that I first thought you were joking. But after a little
experimenting, I think I 'm sold on the crc32. I'll give it a try.
Thanks for the tip.

Regards, Bob S.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

enno
In reply to this post by sturdy
Hi Bob,

> Either method works for me. My suggestion was only a simple option. My
> thought was that any change in the default pattern must mean that the
> user has purposely changed the ID so it should not be touched by
> Gramps. Seems logical to me, sigh.
Well, I think it's not logical, because Gramps must ensure that IDs are
unique to be GEDCOM compliant. And we can only ensure that by changing
IDs automatically when needed.

In other words, IMO allowing users to change IDs is a design flaw. Data
should be manipulated either by the user or the software, but not both,
and for IDs we have an obligation to keep them unique, so they should be
under software control, not user's.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Rich Lakey
I set my own id's for persons and places. Gramps rejects any attempt to set an id that is a duplicate. So there is no worry of my creating duplicates. When I do make a typo that duplicates an id gramps does not force some other id on me but gives me a chance to review the errors of my ways.

On 09/14/2016 04:09 PM, Enno Borgsteede wrote:
Hi Bob,

Either method works for me. My suggestion was only a simple option. My 
thought was that any change in the default pattern must mean that the 
user has purposely changed the ID so it should not be touched by 
Gramps. Seems logical to me, sigh.
Well, I think it's not logical, because Gramps must ensure that IDs are 
unique to be GEDCOM compliant. And we can only ensure that by changing 
IDs automatically when needed.

In other words, IMO allowing users to change IDs is a design flaw. Data 
should be manipulated either by the user or the software, but not both, 
and for IDs we have an obligation to keep them unique, so they should be 
under software control, not user's.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users



------------------------------------------------------------------------------

_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Ron Johnson
In reply to this post by sturdy
On 09/14/2016 04:09 PM, Enno Borgsteede wrote:
[snip]
> In other words, IMO allowing users to change IDs is a design flaw. Data
> should be manipulated either by the user or the software, but not both,
> and for IDs we have an obligation to keep them unique, so they should be
> under software control, not user's.

As a DBA, I disagree with that stance because PKs, FKs and other constraints
in a DB design to the 3NF are perfectly capable of keeping the data consistent.

--
World Peace Through Nuclear Pacification


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

enno
Op 15-09-16 om 03:01 schreef Ron Johnson:
> On 09/14/2016 04:09 PM, Enno Borgsteede wrote:
> [snip]
>> In other words, IMO allowing users to change IDs is a design flaw. Data
>> should be manipulated either by the user or the software, but not both,
>> and for IDs we have an obligation to keep them unique, so they should be
>> under software control, not user's.
> As a DBA, I disagree with that stance because PKs, FKs and other constraints
> in a DB design to the 3NF are perfectly capable of keeping the data consistent.
I know that, but Gramps does not use a relational database right now,
and even if it would use that, the visible IDs are not used as keys at
all. Internal consistency is based on handles which are much longer and
pretty much unreadable for normal humans.

The Gramps database is not normalized either, btw, and foreign keys
constraints are not known to the database, but only to developers. They
are maintained by our own code.

But even if we can ensure the uniqueness of IDs, I think that the idea
to make them editable was a bad one, because it gives users a sense of
control that immediately disappears when you step outside the Gramps
bubble. All popular programs that I know treat IDs as numbers, and put
letters in front of them just for GEDCOM, so if you use another program
next to Gramps, like I do to exchange data with FamilySearch, all your
carefully maintained IDs are basically lost in space.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

Ron Johnson
In reply to this post by Ron Johnson
On 09/16/2016 12:53 AM, Enno Borgsteede wrote:

> Op 15-09-16 om 03:01 schreef Ron Johnson:
>> On 09/14/2016 04:09 PM, Enno Borgsteede wrote:
>> [snip]
>>> In other words, IMO allowing users to change IDs is a design flaw. Data
>>> should be manipulated either by the user or the software, but not both,
>>> and for IDs we have an obligation to keep them unique, so they should be
>>> under software control, not user's.
>> As a DBA, I disagree with that stance because PKs, FKs and other constraints
>> in a DB design to the 3NF are perfectly capable of keeping the data consistent.
> I know that, but Gramps does not use a relational database right now,
> and even if it would use that, the visible IDs are not used as keys at
> all. Internal consistency is based on handles which are much longer and
> pretty much unreadable for normal humans.

IIRC, that changed in 4.x.

> The Gramps database is not normalized either, btw, and foreign keys
> constraints are not known to the database, but only to developers. They
> are maintained by our own code.

Maybe in 5.future!

--
World Peace Through Nuclear Pacification


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed feature requests for Reorder Gramps ID plugin.

enno
Op 16-09-16 om 13:41 schreef Ron Johnson:
> On 09/16/2016 12:53 AM, Enno Borgsteede wrote:
>> I know that, but Gramps does not use a relational database right
>> now,and even if it would use that, the visible IDs are not used as
>> keys at all. Internal consistency is based on handles which are much
>> longer and pretty much unreadable for normal humans.
> IIRC, that changed in 4.x.
No, and I don't think it will ever change. Handles are much safer that
IDs, and much easier too, for the very reason that they're fully
controlled by software. Every table has one, as you can see here:

https://gramps-project.org/wiki/index.php?title=Using_database_API
>> The Gramps database is not normalized either, btw, and foreign keys
>> constraints are not known to the database, but only to developers. They
>> are maintained by our own code.
> Maybe in 5.future!
I hope so, yes, because it would make a couple of things much easier,
like cleaning up duplicate events, connecting to FamilySearch, improving
locations, etc.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users