I have seen it with three different INDI IDs. In each case, the error message was the only symptom--the charts and things still found and used the default person.
Could it have anything to do with the fact that all three IDs were in the format /[A-Z]{3}-1[0-9]{3}/ rather than /I[0-9]+/ ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've also seen it on one other page... I'll have to go back and figure out which one it was. I'm using the latest code in SVN (well, as of a week ago or so). But it's the same way for me, I get the error displayed, but everything actually works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wes
YES, this has to do with your mneumonics INDI-id.
As Gerry has pointed out in the HELP section response, PGV is not designed to function properly without a naming convention where groups all begin with a similar device. INDI/FAM/SOUR etc.
This is not a bug, IOHO.
-stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stephen - in this case I think it *is* a bug. The code is reading the raw gedcom file to find the root person. It can't use the DB, as the file may not have been imported.
It reads the file in 4KB chunks, looking for "0 @xxxx@". If it doesn't find it, it moves on to the next 4KB chunk.
Now, if the "0 @xxxx@" happens to span a 4KB boundary, it won't be found. Statistically, I'd expect about 1 in 500 cases to fail. (If people pick I1, which will always be in the first 4KB block, the actual failure rate would be much lower).
The error is editconfig_gedcoms.php in the block of code around line 646.
We could fix the problem by replacing it with the similar code from the main import routine. However, this would only reveal a subsequent problem: if we update the DB, but don't synchronise the file, we'll be looking at out-of-date records and get a mismatch.
Finally, and this is getting off the point, I think we should update our data model to include representations of "objects" and "facts" (corresponding to level 0 and level 1 tags). If we did this, we wouldn't need to rely on the prefixes (although we could still use them for generating new records).
I've already started to code this for 4.2, but it's a lot of work and might take until 4.3 :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're probably both right--the 4K thing seems like a bug to me, BUT it's unlikely that I would just happen to hit it three times in a row with three different IDs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fix verified for all details except the ~ The presence of an unescaped U+007E changes all following text to upper case.
This may cause confusion for admins who need a tilde in a URI and don't know to change it to %7E
If this feature is needed, then it would be good for something on the edit form to explain it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem was that autocomplete was trying to look up a name in the DB, and the code was looking up the ID in the file, which you can't do when the DB and GEDCOM file are out of sync.
We now only try to lookup these details when we can be sure they exist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 100 days (the time period specified by
the administrator of this Tracker).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1466942
Originator: NO
Looking at the code, it would appear that if the "0 @I1@ INDI" text happens to span a 4K text boundary, then it won't be found.
If you change the ID to a different person, does the error disappear?
Logged In: YES
user_id=1537714
Originator: YES
I have seen it with three different INDI IDs. In each case, the error message was the only symptom--the charts and things still found and used the default person.
Could it have anything to do with the fact that all three IDs were in the format /[A-Z]{3}-1[0-9]{3}/ rather than /I[0-9]+/ ?
Logged In: YES
user_id=1293534
Originator: NO
I've also seen it on one other page... I'll have to go back and figure out which one it was. I'm using the latest code in SVN (well, as of a week ago or so). But it's the same way for me, I get the error displayed, but everything actually works fine.
Logged In: YES
user_id=1061833
Originator: NO
Wes
YES, this has to do with your mneumonics INDI-id.
As Gerry has pointed out in the HELP section response, PGV is not designed to function properly without a naming convention where groups all begin with a similar device. INDI/FAM/SOUR etc.
This is not a bug, IOHO.
-stephen
Logged In: YES
user_id=1466942
Originator: NO
Stephen - in this case I think it *is* a bug. The code is reading the raw gedcom file to find the root person. It can't use the DB, as the file may not have been imported.
It reads the file in 4KB chunks, looking for "0 @xxxx@". If it doesn't find it, it moves on to the next 4KB chunk.
Now, if the "0 @xxxx@" happens to span a 4KB boundary, it won't be found. Statistically, I'd expect about 1 in 500 cases to fail. (If people pick I1, which will always be in the first 4KB block, the actual failure rate would be much lower).
The error is editconfig_gedcoms.php in the block of code around line 646.
We could fix the problem by replacing it with the similar code from the main import routine. However, this would only reveal a subsequent problem: if we update the DB, but don't synchronise the file, we'll be looking at out-of-date records and get a mismatch.
Finally, and this is getting off the point, I think we should update our data model to include representations of "objects" and "facts" (corresponding to level 0 and level 1 tags). If we did this, we wouldn't need to rely on the prefixes (although we could still use them for generating new records).
I've already started to code this for 4.2, but it's a lot of work and might take until 4.3 :-)
Logged In: YES
user_id=1537714
Originator: YES
You're probably both right--the 4K thing seems like a bug to me, BUT it's unlikely that I would just happen to hit it three times in a row with three different IDs.
Logged In: YES
user_id=1006499
Originator: NO
Greg, assigning this one to you :
<<I've already started to code this for 4.2>>
Logged In: YES
user_id=1466942
Originator: NO
I'm not sure what I'm supposed to be doing to this one, so unassigning...
The autocomplete is now only shown when editing an existing gedcom settings.
When creating/uploading new, a search would be meaningless, as we don't yet have the data to search.
I don't understand the connection between autocomplete and a minor bug discovered before autocomplete existed.
Fix verified for all details except the ~ The presence of an unescaped U+007E changes all following text to upper case.
This may cause confusion for admins who need a tilde in a URI and don't know to change it to %7E
If this feature is needed, then it would be good for something on the edit form to explain it.
OOPS, ignore the "Fix verified for all details"--I was on the wrong "artifact"
The problem was that autocomplete was trying to look up a name in the DB, and the code was looking up the ID in the file, which you can't do when the DB and GEDCOM file are out of sync.
We now only try to lookup these details when we can be sure they exist.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 100 days (the time period specified by
the administrator of this Tracker).