#1158 Date sorting requests

open-fixed
None
5
2009-11-01
2009-10-20
Wes Groleau
No

1. If GUID is displayed, put it last. (In fact, it would be nice to keep it last in exported GEDCOM also) I have seen it appearing in the middle of an INDI's life events.

2. If OCCU has no date, sort it as if its date is close to the date of first marriage (if known) or after GRAD or MILI (if present) or 18 years after known or estimated BIRT. I have seen it appearing between BIRT and infant BAPM

Discussion

  • Anonymous - 2009-10-20

    Wes, two good suggestions.

    The second sounds complex, but I see the point. Similar computations are done for other items, so it should be possible.

    I had another thought about the GUID (even though I don't use it). Its not really an event at all, so wouldn't it be better placed in the INDI header area?

     
  • Wes Groleau

    Wes Groleau - 2009-10-20

    Does anyone use it?
    Putting it outside of the fact list seems trickier to me than sorting it last.
    I'd say it should be with the change info, and if outside of the fact list, lower on the page.

     
  • Anonymous - 2009-10-21

    GUID - "Does anyone use it"

    Well, I guess "use" is the keyword there. I see loads of sites that "display" it, but I would suspect 99% of them don't even know what it is.

    Greg's merge code/patch did use it as a unique identifier, but no, apart from that I know of no real "use".

    I try to remove it from any data I receive, but just in case, I also suppress its display from all types of users (even Admin) in privacy settings, so I don't really care where it gets put :-).

     
  • Greg Roach

    Greg Roach - 2009-10-21

    From a developers point of view, these GUIDs are extremely useful.

    I would like to have the "add UIDS on import" option made mandatory ;-)

    If you don't want to see them, simply set the fact privacy to "hide, even from admins".

    Sorting is easy to fix. Just decide what order you want. Should _UID be last, or should CHAN be last or should _TODO be last or should AFN be last, etc.

     
  • Wes Groleau

    Wes Groleau - 2009-10-21

    Greg, do you mean we have to decide for coding changes, or we have to decide for some config setting I wasn't aware of?

     
  • Greg Roach

    Greg Roach - 2009-10-21

    The order is hard-coded. There is no config option.

    _UID isn't in the list, so its sort order is undefined.

    I could add it (in last place), as you request, but that might annoy people who are happy that CHAN and TODO are currently the final facts.

    It's not worth the effort to write a config option for this (and support and translate it).

     
  • Anonymous - 2009-10-22

    As earlier, I'm only interested academically, but my preference would be _TODO, then any reference numbers (AFN, GUID etc) in alphabetic order by tag name), then CHAN last.

    Greg, presumably if UIDs were to be created on import, they woud also need to be created on ADD as well?

    These numbers do intrigue me though. Are they really "unique"?, whats stopping someone else generating a UID the same as one I use, for a completely different INDI?, and how do they / can they help with things like merging? Surely John Smith on my tree, and the same John Smith on your tree will have different UIDs just like they have different INDI refs? (Sorry getting well off Wes' request here)

     
  • Wes Groleau

    Wes Groleau - 2009-10-23

    I didn't mean to stir up such a storm.
    I consider it minor, and in fact, on my site, only an admin will see it.
    That said, I suppose my preference would be the same as the Kiwi's.

    The OCCU interests me more, but it, too, is minor.

     
  • Greg Roach

    Greg Roach - 2009-10-29

    <<they woud also need to be created on ADD as well?>>

    If the option is set, then they are. The code is in the "add gedcom record to database" logic.

    PGV UUID's are a "poor man's" version, and only as good as your random number generator. A "proper" uuid, as generated by MySQL uses the mac address, the microsecond timestamap and a random number. They can generallyl be relied on to be unique.

    Wes - the sort algorithm has to work on pairs of events, and cannot easily look to see age/marriage, etc. We cn only set it's order relative to other events. e.g. After MARR. I'll look at these when I get back to my home computer.

     
  • Greg Roach

    Greg Roach - 2009-10-29

    <<and how do they / can they help with things like merging?>>

    I do it by copying them back/forth. Thus after a merge, each INDI gets two UUIDs - one from each gedcom. It allows them to be matched if you subsequently edit/remerge either gedcom.

     
  • Greg Roach

    Greg Roach - 2009-10-31

    Undated OCCU sorts after MARR, BIRT_CHIL and CENS. This seems right to me. If you're not seeing this, then IIRC there is an open bug report for sorting (assigned to yalnifj??).

    I've added _UID with the other reference numbers.

    I've left _TODO last, after CHAN. I think it is important that this one stands out.

     
  • Greg Roach

    Greg Roach - 2009-10-31
    • assigned_to: nobody --> fisharebest
    • status: open --> pending-fixed
     
  • Wes Groleau

    Wes Groleau - 2009-11-01

    Yes, I am and have been seeing that.
    What triggered the second part was seeing an undated OCCU before a BAPM that was done in infancy (I suppose I should have used CHR.
    This is still happening on P1611 but not on P1360. DB = http://UniGen.us/PGV/ which is at SVN 1691

     
  • Wes Groleau

    Wes Groleau - 2009-11-01
    • status: pending-fixed --> open-fixed
     
  • Wes Groleau

    Wes Groleau - 2009-11-01

    Aarrgghh! It's 6291 !!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks