custom ID formats

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

custom ID formats

Paul Franklin-5
A user reported a problem with his so I am curious.

I know that a user's ID formats are stored in the
.../grampsNN/gramps.ini file.

Are they also stored in the database?  If so, how
and where?  Are they in the metadata for instance?
If not, should they be?

When a gramps-XML export is made, are the user's
ID format choices exported?  If so, how and where?
If not, should they be?

Most importantly, when a user upgrades their gramps,
what if anything makes the ID formats be anything
other that the default four-number length (assuming
of course that they were not four numbers before)?

That is to say, are the user's various *.ini choices
transferred from the old grampsMM/gramps.ini to a
new grampsNN/gramps.ini file?  If so, how and where?

For instance, if the user already had five-digit places
when a 3.x.y to 4.1.3 Place upgrade happens, are the
new places made with five digits, if the gramps.ini
contains just the default four-digit formats?

Thanks.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

enno
Hi Paul,
> A user reported a problem with his so I am curious.
>
> I know that a user's ID formats are stored in the
> .../grampsNN/gramps.ini file.
>
> Are they also stored in the database?  If so, how
> and where?  Are they in the metadata for instance?
> If not, should they be?
I have no idea. I don't do conversions myself, but create a new database
and then import a 3.4 tree from XML.
> When a gramps-XML export is made, are the user's
> ID format choices exported?  If so, how and where?
> If not, should they be?
I haven't checked my .gramps file, but they sure aren't imported. And I
think they should be.
> Most importantly, when a user upgrades their gramps,
> what if anything makes the ID formats be anything
> other that the default four-number length (assuming
> of course that they were not four numbers before)?
Nothing. The user has to set preferences again.
> That is to say, are the user's various *.ini choices
> transferred from the old grampsMM/gramps.ini to a
> new grampsNN/gramps.ini file?  If so, how and where?
No.
> For instance, if the user already had five-digit places
> when a 3.x.y to 4.1.3 Place upgrade happens, are the
> new places made with five digits, if the gramps.ini
> contains just the default four-digit formats?
No, they get 4 digits until the table has grown large enough to need more.

regards,

Enno


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

Oldest1
In reply to this post by Paul Franklin-5
On 7/15/2015 12:36 PM, Paul Franklin wrote:
> A user reported a problem with his so I am curious.
>
> I know that a user's ID formats are stored in the
> .../grampsNN/gramps.ini file.
Interesting problem.
IMO, all data which affects the data(base), ought to be
stored there
and become part of any update, just as all other data would
- hopefully- be either transferred, or, where necessary
because of
a change in policy - such as limiting the size, of in this
case the IDs
to less than the existing limit (purely a hypothetical case,
I expect),
the user would be given reasonable options to comply with
such new
requirements

>
> Are they also stored in the database?  If so, how
> and where?  Are they in the metadata for instance?
> If not, should they be?
>
> When a gramps-XML export is made, are the user's
> ID format choices exported?  If so, how and where?
> If not, should they be?
>
> Most importantly, when a user upgrades their gramps,
> what if anything makes the ID formats be anything
> other that the default four-number length (assuming
> of course that they were not four numbers before)?
>
> That is to say, are the user's various *.ini choices
> transferred from the old grampsMM/gramps.ini to a
> new grampsNN/gramps.ini file?  If so, how and where?
>
> For instance, if the user already had five-digit places
> when a 3.x.y to 4.1.3 Place upgrade happens, are the
> new places made with five digits, if the gramps.ini
> contains just the default four-digit formats?
>
> Thanks.
>
--
Fight Spam - report it with wxSR 0.7
Vista & Win7 compatible
http://www.columbinehoney.net/wxSR.shtml


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

DS Blank
In reply to this post by Paul Franklin-5
On Wed, Jul 15, 2015 at 3:36 PM, Paul Franklin <[hidden email]> wrote:
A user reported a problem with his so I am curious.

I know that a user's ID formats are stored in the
.../grampsNN/gramps.ini file.

Are they also stored in the database?  If so, how
and where?  Are they in the metadata for instance?
If not, should they be?

They are not stored in the database. They are only stored in the .ini file.

If each database had its own formatting, then you'd need to manage that for each. I guess the original decision was made that there is only ever one definition. It could get complicated if you wanted to have a default for the defaults.
 

When a gramps-XML export is made, are the user's
ID format choices exported?  If so, how and where?
If not, should they be?


No, they are not exported in any export format.
 
Most importantly, when a user upgrades their gramps,
what if anything makes the ID formats be anything
other that the default four-number length (assuming
of course that they were not four numbers before)?

I think that this is the bug: when upgrading gramps, the old id_prefix patterns are not copied from the old .ini. This should be easy to fix.
 

That is to say, are the user's various *.ini choices
transferred from the old grampsMM/gramps.ini to a
new grampsNN/gramps.ini file?  If so, how and where?

The code lives in gramps/gen/config.py and gramps/gen/utils/configmanager.py. There is code at the bottom that upgraded from the original keys.ini to gramps.ini. But I don't think anything has been done to transfer old settings to new settings.
 

For instance, if the user already had five-digit places
when a 3.x.y to 4.1.3 Place upgrade happens, are the
new places made with five digits, if the gramps.ini
contains just the default four-digit formats?

Upgrading from the old gramps.ini to a new gramps.ini might be easy, but may also encounter some edge cases that cause problems. Currently, it appears that we just start with a new gramps.ini for each new version of gramps. That avoids any upgrade issues (but loses all of the defaults). For example, if we just use the old values, but the meaning or type has changed, then we need to ignore them.

The workaround is to upgrade to new version, change the id prefixes, then do the import.

-Doug
 

Thanks.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

Paul Franklin-5
Thanks for the explanation, Doug.

On 7/15/15, Doug Blank <[hidden email]> wrote:


>> Are they also stored in the database?  If so, how
>> and where?  Are they in the metadata for instance?
>> If not, should they be?
>
> They are not stored in the database. They are only stored in the .ini file.
>
> If each database had its own formatting, then you'd need to manage that for
> each. I guess the original decision was made that there is only ever one
> definition. It could get complicated if you wanted to have a default for
> the defaults.

It seems to me that letting the existing mechanism
"manage" the formats and then logging the results
into the database is not what you were mentioning,
but might be a lot easier.  That would enable things
to be done later, if desired, but would not force them.


>> When a gramps-XML export is made, are the user's
>> ID format choices exported?  If so, how and where?
>> If not, should they be?
>>
> No, they are not exported in any export format.

"If not, should they be?"  I am proposing "yes".


>> Most importantly, when a user upgrades their gramps,
>> what if anything makes the ID formats be anything
>> other that the default four-number length (assuming
>> of course that they were not four numbers before)?
>
> I think that this is the bug: when upgrading gramps, the old id_prefix
> patterns are not copied from the old .ini. This should be easy to fix.

Do I hear a volunteer?  8-)

(I doubt it would be "easy" for me.)

However, I also think that something similar should
happen when an XML export and import happen. At
the very least I'd think keeping track of the largest
number and then notifying the user /if/ it is larger
that her existing format choice(s) would enable her
to change the format choices and then do another
import (of the same XML file).

And if the choices were in some (new) XML export,
then I would think it would be even easier to do more.


>> That is to say, are the user's various *.ini choices
>> transferred from the old grampsMM/gramps.ini to a
>> new grampsNN/gramps.ini file?  If so, how and where?
>
> The code lives in gramps/gen/config.py and
> gramps/gen/utils/configmanager.py. There is code at the bottom that
> upgraded from the original keys.ini to gramps.ini. But I don't think
> anything has been done to transfer old settings to new settings.

That was my impression too.  I only saw code to
make a new gramps.ini, and nothing to copy old
values (or even some old values), if any, into it

I would argue that old values should be copied over.


>> For instance, if the user already had five-digit places
>> when a 3.x.y to 4.1.3 Place upgrade happens, are the
>> new places made with five digits, if the gramps.ini
>> contains just the default four-digit formats?
>
> Upgrading from the old gramps.ini to a new gramps.ini might be easy, but
> may also encounter some edge cases that cause problems. Currently, it
> appears that we just start with a new gramps.ini for each new version of
> gramps. That avoids any upgrade issues (but loses all of the defaults). For
> example, if we just use the old values, but the meaning or type has
> changed, then we need to ignore them.
>
> The workaround is to upgrade to new version, change the id prefixes, then
> do the import.

Yes, that could be argued.  My counter-argument
would be that in that case /we/ should test for it and
throw up a dialog to tell the user what to do -- /before/
it is too late.  As happened to the user who filed the
report on the bug tracker.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

DS Blank
On Wed, Jul 15, 2015 at 8:01 PM, Paul Franklin <[hidden email]> wrote:
Thanks for the explanation, Doug.

On 7/15/15, Doug Blank <[hidden email]> wrote:


>> Are they also stored in the database?  If so, how
>> and where?  Are they in the metadata for instance?
>> If not, should they be?
>
> They are not stored in the database. They are only stored in the .ini file.
>
> If each database had its own formatting, then you'd need to manage that for
> each. I guess the original decision was made that there is only ever one
> definition. It could get complicated if you wanted to have a default for
> the defaults.

It seems to me that letting the existing mechanism
"manage" the formats and then logging the results
into the database is not what you were mentioning,
but might be a lot easier.  That would enable things
to be done later, if desired, but would not force them.


>> When a gramps-XML export is made, are the user's
>> ID format choices exported?  If so, how and where?
>> If not, should they be?
>>
> No, they are not exported in any export format.

"If not, should they be?"  I am proposing "yes".

I'm not sure what problem that would be solving, and would be import/export code to write and maintain. And some decisions to make: what happens when you import into an existing tree---do you use the importing id prefix, or existing one?
 


>> Most importantly, when a user upgrades their gramps,
>> what if anything makes the ID formats be anything
>> other that the default four-number length (assuming
>> of course that they were not four numbers before)?
>
> I think that this is the bug: when upgrading gramps, the old id_prefix
> patterns are not copied from the old .ini. This should be easy to fix.

Do I hear a volunteer?  8-)

I think the simple, minimal fix would be to just migrate the old gramps.ini to the new one. I can do that, and would solve the issue that the issue was about.
 

(I doubt it would be "easy" for me.)

However, I also think that something similar should
happen when an XML export and import happen. At
the very least I'd think keeping track of the largest
number and then notifying the user /if/ it is larger
that her existing format choice(s) would enable her
to change the format choices and then do another
import (of the same XML file).

I think that is a useful change that could be triggered even on a single data entry: "The ID for new item(s) has surpassed the space allocated. Continue?" Or do allow the new item, but with perhaps a temp id prefix. It is now important that IDs be unique. (There was a time where gramps allowed duplicate IDs, but there is now code that assumes unique gramps IDs).
 

And if the choices were in some (new) XML export,
then I would think it would be even easier to do more.


>> That is to say, are the user's various *.ini choices
>> transferred from the old grampsMM/gramps.ini to a
>> new grampsNN/gramps.ini file?  If so, how and where?
>
> The code lives in gramps/gen/config.py and
> gramps/gen/utils/configmanager.py. There is code at the bottom that
> upgraded from the original keys.ini to gramps.ini. But I don't think
> anything has been done to transfer old settings to new settings.

That was my impression too.  I only saw code to
make a new gramps.ini, and nothing to copy old
values (or even some old values), if any, into it

I would argue that old values should be copied over.

Yes, agreed.
 


>> For instance, if the user already had five-digit places
>> when a 3.x.y to 4.1.3 Place upgrade happens, are the
>> new places made with five digits, if the gramps.ini
>> contains just the default four-digit formats?
>
> Upgrading from the old gramps.ini to a new gramps.ini might be easy, but
> may also encounter some edge cases that cause problems. Currently, it
> appears that we just start with a new gramps.ini for each new version of
> gramps. That avoids any upgrade issues (but loses all of the defaults). For
> example, if we just use the old values, but the meaning or type has
> changed, then we need to ignore them.
>
> The workaround is to upgrade to new version, change the id prefixes, then
> do the import.

Yes, that could be argued.  My counter-argument
would be that in that case /we/ should test for it and
throw up a dialog to tell the user what to do -- /before/
it is too late.  As happened to the user who filed the
report on the bug tracker.

Yes, but that can happen on import and data entry. I think a new Feature Request is warranted for that functionality, and a discussion on what should happen exactly.

-Doug


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

Paul Franklin-5
>> > The workaround is to upgrade to new version, change the id prefixes,
>> > then
>> > do the import.
>>
>> Yes, that could be argued.  My counter-argument
>> would be that in that case /we/ should test for it and
>> throw up a dialog to tell the user what to do -- /before/
>> it is too late.  As happened to the user who filed the
>> report on the bug tracker.
>>
>
> Yes, but that can happen on import and data entry. I think a new Feature
> Request is warranted for that functionality, and a discussion on what
> should happen exactly.

I suppose it depends on whether what we are discussing
is a bug -- as I believe -- or a new feature, as you seem to.

That matters a lot as to when our users will be affected.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Fwd: custom ID formats

Paul Franklin-5
In reply to this post by DS Blank
Sorry.  Blew the cut-and-paste.

---------- Forwarded message ----------
From: Paul Franklin <[hidden email]>
Date: Wed, 15 Jul 2015 19:36:06 -0700
Subject: Re: [Gramps-devel] custom ID formats
To: Doug Blank <[hidden email]>
Cc: [hidden email]

> I'm not sure what problem that would be solving, and would be import/export
> code to write and maintain. And some decisions to make: what happens when
> you import into an existing tree---do you use the importing id prefix, or
> existing one?

As a typical average naive developer, I would assume that
particular situation would be easy to check for, for anybody
who knew enough to be coding it.  I would also assume that
the right thing to do would be to pop up a dialog and ask
the user which choice she wants -- not to force her into one,
perhaps unbeknownst to her.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

DS Blank
In reply to this post by Paul Franklin-5
On Wed, Jul 15, 2015 at 10:40 PM, Paul Franklin <[hidden email]> wrote:
>> > The workaround is to upgrade to new version, change the id prefixes,
>> > then
>> > do the import.
>>
>> Yes, that could be argued.  My counter-argument
>> would be that in that case /we/ should test for it and
>> throw up a dialog to tell the user what to do -- /before/
>> it is too late.  As happened to the user who filed the
>> report on the bug tracker.
>>
>
> Yes, but that can happen on import and data entry. I think a new Feature
> Request is warranted for that functionality, and a discussion on what
> should happen exactly.

I suppose it depends on whether what we are discussing
is a bug -- as I believe -- or a new feature, as you seem to.

That matters a lot as to when our users will be affected.

Since it has always worked this way since the beginning of Gramps, will affect imports, including command-line and other related functions (eg, import_as_dict), affect data entry, needs to have some design decisions, and require new documentation, I think it would be reasonable to consider it a feature request. 

-Doug

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

Paul Franklin-5
In reply to this post by Paul Franklin-5
> I suppose it depends on whether what we are discussing
> is a bug -- as I believe -- or a new feature, as you seem to.
>
> That matters a lot as to when our users will be affected.

One of our users posted a message to gramps-devel today
saying he had the exact problem I was trying to prevent,
when I said that ID formats should be included in the XML.

So I still think the problem should be fixed that way, and
ideally fast enough that it could make it into 4.2.1.

Rather than at some (possibly far-future) time, after long
hours of discussing things.

I certainly don't want it forgotten, which is what I am afraid of.

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

Re: custom ID formats

DS Blank
On Mon, Jul 27, 2015 at 1:44 PM, Paul Franklin <[hidden email]> wrote:
> I suppose it depends on whether what we are discussing
> is a bug -- as I believe -- or a new feature, as you seem to.
>
> That matters a lot as to when our users will be affected.

One of our users posted a message to gramps-devel today
saying he had the exact problem I was trying to prevent,
when I said that ID formats should be included in the XML.

So I still think the problem should be fixed that way, and
ideally fast enough that it could make it into 4.2.1.

Rather than at some (possibly far-future) time, after long
hours of discussing things.

I certainly don't want it forgotten, which is what I am afraid of.

There is now a feature request for upgrading from previous gramps.ini files:


and a fix applied to master. Please test this out. If we feel that this solves the original problem (overflowing IDs) and doesn't create other issues, we can consider it for gramps 4.2.0 (or 4.2.1 to be more safe).

-Doug

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

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

Re: custom ID formats

enno
Doug,
> There is now a feature request for upgrading from previous gramps.ini
> files:
>
> https://gramps-project.org/bugs/view.php?id=8772
>
> and a fix applied to master. Please test this out. If we feel that
> this solves the original problem (overflowing IDs) and doesn't create
> other issues, we can consider it for gramps 4.2.0 (or 4.2.1 to be more
> safe).
A previous email did not make it to the list, so here's a shortened one.

Copying settings on upgrade is nice, and welcome, but it doesn't solve
the problem of copying settings when you work on one tree on two
machines. I use my laptop in weekends, and until now, I haven't bothered
with the settings on that, meaning that when I import my 5 digit .gramps
backup on that, all IDs below 10,000 do turn into 4 digit ones again.

This is not a big problem, because many times I don't make changes on
that laptop, and even when I do, the next import into my desktop will
return all IDs to their original size. I would appreciate having these
settings, and also things like name and date formats, as file options,
so that they are restored whenever I import a .gramps backup into an
empty tree, or open the .gramps file directly.

This would mean that like RootsMagic, we would distinguish between file
and program options, which I think would make a few things more clear,
for instance when it comes to researcher vs. file owner, which can be
set in different menus now.

regards,

Enno


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

Re: custom ID formats

DS Blank
On Fri, Jul 31, 2015 at 10:48 AM, Enno Borgsteede <[hidden email]> wrote:
Doug,
> There is now a feature request for upgrading from previous gramps.ini
> files:
>
> https://gramps-project.org/bugs/view.php?id=8772
>
> and a fix applied to master. Please test this out. If we feel that
> this solves the original problem (overflowing IDs) and doesn't create
> other issues, we can consider it for gramps 4.2.0 (or 4.2.1 to be more
> safe).
A previous email did not make it to the list, so here's a shortened one.

Copying settings on upgrade is nice, and welcome, but it doesn't solve
the problem of copying settings when you work on one tree on two
machines.

Enno,

I agree; the problem you identify is a separate issue.
 
I use my laptop in weekends, and until now, I haven't bothered
with the settings on that, meaning that when I import my 5 digit .gramps
backup on that, all IDs below 10,000 do turn into 4 digit ones again.

That seems like a bug to me. I wouldn't think that Gramps needs to mess with the gramps_id at all on a XML import. If a user wants to change the gramps_ids, that should be done after import. If it didn't mess with them, is there ever a situation where they would be truncated like you describe?
 

This is not a big problem, because many times I don't make changes on
that laptop, and even when I do, the next import into my desktop will
return all IDs to their original size. I would appreciate having these
settings, and also things like name and date formats, as file options,
so that they are restored whenever I import a .gramps backup into an
empty tree, or open the .gramps file directly.

This would mean that like RootsMagic, we would distinguish between file
and program options, which I think would make a few things more clear,
for instance when it comes to researcher vs. file owner, which can be
set in different menus now.

I guess before implementing more complexity in the defaults for gramps_ids, I'd like the program to do the right thing. 

Do you think that simply turning off the auto-reformating on XML import would be an improvement?

-Doug
 

regards,

Enno


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


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

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

Re: custom ID formats

Rich Lakey
This post has NOT been accepted by the mailing list yet.
In reply to this post by enno
What am I missing here? I copy my 4.0.4 database to my laptop running 4.1.3 and 4.1.3 preserves my 11 character place ID when it converts the database to the new format. Also my custom person ids are preserved.
Reply | Threaded
Open this post in threaded view
|

Re: custom ID formats

Helge.Herz-2
In reply to this post by DS Blank
Am 31.07.2015 17:13, schrieb Doug Blank:
> ...
> Do you think that simply turning off the auto-reformating on XML import
> would be an improvement?
> ...
So far my experiences the current state is that only IDs are reformatted
if they matching the current definition rule.
Examples:
definition: E%04d
--> any incoming ID Ennn (n are digits) will be forced to be E0nnn
--> any incoming ID Exnnnn (x, n are digits) will be forced to be Ennnn
with the described issue
--> any incoming ID EBnnnn (B is a letter or a character like "#", n are
digits) will be unchanged

definition: EB%4d
--> only incoming IDs starting with EB will be reformatted.
But using the tool "reorder Gramps ID's" forces all IDs to follow the
definition in preferences.

Because I use my own ID definitions in some cases (e.g. to mark the
evidence of events and to control source and media IDs - the later as my
archive numbers) I prefer to have the system as it is to day.
Any changes for auto-reformating on XML import should be an option.
I would like have too the tool "reorder Gramps ID's" with the option to
select which ID to be reordered (I know it's a feature request I have to
file...)
- Helge


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

Re: custom ID formats

enno
Hi Helge,

> Am 31.07.2015 17:13, schrieb Doug Blank:
>> ...
>> Do you think that simply turning off the auto-reformating on XML import
>> would be an improvement?
>> ...
> So far my experiences the current state is that only IDs are reformatted
> if they matching the current definition rule.
> Examples:
> definition: E%04d
> --> any incoming ID Ennn (n are digits) will be forced to be E0nnn
> --> any incoming ID Exnnnn (x, n are digits) will be forced to be Ennnn
> with the described issue
Only if x is not 0, right? That's what I see when I import my tree in
another Gramps with %04d everywhere. IDs are only shortened when the
number actually fits inside %04d, meaning that it's below 10,000.
> --> any incoming ID EBnnnn (B is a letter or a character like "#", n are
> digits) will be unchanged
Have you checked what happens when you import the same XML twice? If IDs
like EBnnnn are never changed, you'd get duplicates, and I really hope
that Gramps can prevent that. I know that Ancestry used P%d in person
IDs, and have reformatted those to keep my tree consistent.

regards,

Enno


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

Re: custom ID formats

enno
In reply to this post by DS Blank
Hi Doug,
 
I use my laptop in weekends, and until now, I haven't bothered
with the settings on that, meaning that when I import my 5 digit .gramps
backup on that, all IDs below 10,000 do turn into 4 digit ones again.

That seems like a bug to me. I wouldn't think that Gramps needs to mess with the gramps_id at all on a XML import. If a user wants to change the gramps_ids, that should be done after import. If it didn't mess with them, is there ever a situation where they would be truncated like you describe?
XML imports can occur in any database, empty or not, and the imported XML may be old and have duplicate IDs itself. For that reason, Gramps must do some sort of processing on them. Switching reformatting off when importing to an empty database is risky.
 

This is not a big problem, because many times I don't make changes on
that laptop, and even when I do, the next import into my desktop will
return all IDs to their original size. I would appreciate having these
settings, and also things like name and date formats, as file options,
so that they are restored whenever I import a .gramps backup into an
empty tree, or open the .gramps file directly.

This would mean that like RootsMagic, we would distinguish between file
and program options, which I think would make a few things more clear,
for instance when it comes to researcher vs. file owner, which can be
set in different menus now.

I guess before implementing more complexity in the defaults for gramps_ids, I'd like the program to do the right thing. 

Do you think that simply turning off the auto-reformating on XML import would be an improvement?
No, for reasons mentioned above. We need unique IDs, and turning it off on empty databases may lead to duplicate IDs if such exist in the XML. It also makes the import code more complicated, and I assume that there's not much gain in speed either.

What I do like is to use the formats from the XML if the receiving database is empty, not only for IDs, but also for names, places, etc.

regards,

Enno


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

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

Re: custom ID formats

DS Blank
On Thu, Aug 6, 2015 at 10:48 AM, Enno Borgsteede <[hidden email]> wrote:
Hi Doug,
 
I use my laptop in weekends, and until now, I haven't bothered
with the settings on that, meaning that when I import my 5 digit .gramps
backup on that, all IDs below 10,000 do turn into 4 digit ones again.

That seems like a bug to me. I wouldn't think that Gramps needs to mess with the gramps_id at all on a XML import. If a user wants to change the gramps_ids, that should be done after import. If it didn't mess with them, is there ever a situation where they would be truncated like you describe?
XML imports can occur in any database, empty or not, and the imported XML may be old and have duplicate IDs itself. For that reason, Gramps must do some sort of processing on them. Switching reformatting off when importing to an empty database is risky.

Right... I meant that Gramps should not mess with valid, unique Gramps IDs on import, even if they don't match the currently defined ID pattern. Reformatting IDs should be a separate step.
 

 

This is not a big problem, because many times I don't make changes on
that laptop, and even when I do, the next import into my desktop will
return all IDs to their original size. I would appreciate having these
settings, and also things like name and date formats, as file options,
so that they are restored whenever I import a .gramps backup into an
empty tree, or open the .gramps file directly.

This would mean that like RootsMagic, we would distinguish between file
and program options, which I think would make a few things more clear,
for instance when it comes to researcher vs. file owner, which can be
set in different menus now.

I guess before implementing more complexity in the defaults for gramps_ids, I'd like the program to do the right thing. 

Do you think that simply turning off the auto-reformating on XML import would be an improvement?
No, for reasons mentioned above. We need unique IDs, and turning it off on empty databases may lead to duplicate IDs if such exist in the XML. It also makes the import code more complicated, and I assume that there's not much gain in speed either.

Right, it should verify, and renumber only if necessary.

-Doug
 

What I do like is to use the formats from the XML if the receiving database is empty, not only for IDs, but also for names, places, etc.

regards,

Enno



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

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

Re: custom ID formats

Helge.Herz-2
In reply to this post by enno
Hi Enno,

I just recognise effects / differences if the import runs into an empty
database or doing an import twice in the same database. I've to do more
trials. My former description doesn't be complete.
BTW: Importing a xml twice doubles the markers :-(
- Helge

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

Re: custom ID formats

enno
Hi Helge,
> I just recognise effects / differences if the import runs into an empty
> database or doing an import twice in the same database. I've to do more
> trials. My former description doesn't be complete.
> BTW: Importing a xml twice doubles the markers :-(
You mean tags? I remember reading that before.

While testing #8803, I discovered that a repeated GEDCOM import creates
duplicate event IDs. Not nice.

Media IDs are messed up a bit too. In the FTM GEDCOM, tags look like
M%d, where Gramps expects O%04d. In the 1st round, FTM's IDs are
preserved, in 2nd and 3rd, new IDs are created according to the O%04d
pattern. This is probably like you wish to preserve tags, but I doubt
whether all users think like that.

Renumbering Gramps IDs cures both, btw.

regards,

Enno


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