From: Douglas S. B. <db...@cs...> - 2007-02-15 16:16:05
|
ben...@ug... wrote: > Thinking deeper on this, I do see some problems. > > Having attributes which are no longer correct is not a nice prospect. Eg, you > change the birth date but the 'Age at death' attribute is still the old one. Yes, this is actually why I was originally focusing on the "virtual" aspect--- they will never be out of sync. But this will never work for virtual values that take some time to compute; they need to be pre-computed and stored. So the attribute is the way to go. > Perhaps attributes which are rules can be introduced? > Note that I have asked for a feature once: double valued key attributes > (related > to genetics). Here one could eg have key1: 'age at date', key2: '1830', value: > '52'. Can you explain this a bit more (or point me to the previous discussion)? I don't understand "double valued key attributes" nor your example about keys. I was thinking about some rules that would get triggered by certain messages. Tools could insert rules, and have associated actions. I'm imagining: rule-0001: IF birth_date CHANGES THEN function_0001() rule-0002: IF death_date CHANGES THEN function_0002() where function_000x() would do the appropriate updates. Thanks! -Doug > Food for thought > > Benny > > Quoting ben...@ug...: > >> Yes, I like this idea a lot too. >> >> Douglas, as CSV export is in 2.3 and Don and Taylor will rewrite the column >> code, I think it best to do your efforts in 2.3 too. >> >> So to recap and list the efforts for this, as well as possible pitfalls: >> >> 1/the column editor allows to select attributes to show in the list view. >> Question: What with doubles? How to select them? ... >> >> 2/a tool to set age related attributes. Which attribute key? Just >> delete old and >> recalculate? >> >> 3/Would a button on the attribute list of person also not be needed, so >> that the >> tool can be run for only one person, on the attribute list? Eg an icon under >> the +, edit, - icon of attribute? >> >> Advantages: >> 1/a general framework usable for all attributes >> 2/attribute code can be reused, eg for output of data to reports >> 3/any calculation time with estimated death, ... is limited to a tool. >> >> Benny >> >> Quoting "Douglas S. Blank" <db...@cs...>: >> >>> On Thu, February 15, 2007 8:56 am, Don Allingham wrote: >>>> I'm coming late to this discussion, but I'm thinking that it might be >>>> better to write a tool that would go through the database and add "Age >>>> at Death", "Age on Date", "Age on XXX event" as attributes. People may >>>> want this as something to include in reports. Once this has been added >>>> as a attribute in the database, anything can use it, and the user can >>>> change the value if new information comes to light. >>>> >>>> Also, once this is done, we could create a more generic column display >>>> that would display the value of any attribute, making the much more >>>> flexible. >>> I'd be in favor of pursing this line of thought. Although it will have a >>> slight impact on the time to display a row, judging from the experiments I >>> did, it should not have a significant impact. This would address Benny's >>> concern about having a computed column value not displayed anywhere (it >>> would be an attribute), and this could allow me to have my intensive >>> algorithm to compute estimated age (which could even be a plugin). >>> >>> The code for figuring out what columns to display will have to be changed >>> significantly, but that would be for the better. I really didn't like the >>> idea of changing the GrampsDB core format in order to add a virtual >>> column. The column data will have to be stored *in* the database, rather >>> than altering the database structure. >>> >>> -Doug >>> >>>> Sorry if this has already be discussed - I'm trying to skim things as >>>> fast as I can to catch up on the 1578 messages in my inbox :-) >>>> >>>> Don >>>> >>>> On Thu, 2007-02-15 at 08:47 -0500, Douglas S. Blank wrote: >>>>> On Thu, February 15, 2007 5:51 am, ben...@ug... wrote: >>>>>> Douglas, >>>>>> >>>>>> great that it has no impact on performance. I did not understand >>>>>> however if with >>>>>> old columns you mean the official 2.2.6 branch, or your changed code >>>>>> without >>>>>> showing the age columns. The way I understand the view, the database >>>>> is >>>>>> completely scanned to make the sorting on name. If I understand >>>>> correctly >>>>>> your >>>>>> field is only calculated when it has to be shown on screen, but >>>>> perhaps it >>>>>> calculated even if not shown? Anyway, you should compare 2.2.6 with >>>>> your >>>>>> changes in case you didn't do that now. >>>>> Benny, >>>>> >>>>> I only compute the column data when it is needed, and then it is cached, >>>>> just like the other fields. The timing data reported below is based on >>>>> the >>>>> official 2.2.6 tree. >>>>> >>>>>> I do think that if you add extra fields to the person view, you should >>>>>> make sure >>>>>> these fields also are available in the Person Dialog. It would be >>>>> strange >>>>>> I >>>>>> think to see more information in the list view than in the detailed >>>>> dialog >>>>>> view. >>>>> I'll check into that next. I think "Age at Death" and "Age on Date" >>>>> would >>>>> be useful in other places, such as some reports. >>>>> >>>>>> You say you don't change tables, I suppose you mean database tables. >>>>> So >>>>>> how do >>>>>> you then calculate the probable age of people of who birth/death is >>>>>> unknown? Or >>>>>> did you not tackle that yet? >>>>> The age columns currently just show values for which we have specific >>>>> data >>>>> (birth date, or birth date and death date) for each person. Haven't done >>>>> the estimate part yet. That might be a more serious change, although >>>>> I'll >>>>> try to work within the GRAMPS framework. Maybe an attribute? Any ideas? >>>>> >>>>> -Doug >>>>> >>>>>> Benny >>>>>> >>>>>> Quoting "Douglas S. Blank" <db...@cs...>: >>>>>> >>>>>>> ben...@ug... said: >>>>>>> >>>>>>>> Doug, >>>>>>>> >>>>>>>> Although extra columns would fit the needs you put forward, there >>>>> are >>>>>>>> still some problems. >>>>>>>> >>>>>>>> I think you must understand it is extremely unlikely that much extra >>>>>>>> columns are >>>>>>>> added, let alone columns that need processing time to calculate. >>>>>>>> Performance of >>>>>>>> the people view is very important. >>>>>>> Ok, fair enough. So the main concern is how it effects the people >>>>> view, >>>>>>> and I hadn't looked at the speed impact at all. I have now performed >>>>>>> tests >>>>>>> on these new columns with a database of over 100,000 (of real data). >>>>> Two >>>>>>> places one would notice time differences would be when expanding all >>>>>>> nodes >>>>>>> in the people view, and when scrolling. >>>>>>> >>>>>>> I did a variety of experiments, with and without the new columns. I >>>>>>> timed >>>>>>> (with just my watch, nothing fancy) expanding and collapsing all >>>>> rows. I >>>>>>> found the following. Time to: >>>>>>> >>>>>>> expand default old columns: 9 seconds >>>>>>> expand all old columns : 8 seconds >>>>>>> collapse columns : 7 seconds >>>>>>> expand just age at death : 6 seconds >>>>>>> expand new and old cols : 8 seconds >>>>>>> expand just new columns : 7 seconds >>>>>>> >>>>>>> So, the computation on these new columns does not add to the time to >>>>>>> expand the columns. It takes between 6 seconds and 9 seconds, >>>>> regardless >>>>>>> of what one is showing or not showing. >>>>>>> >>>>>>> Next, I tested scrolling from top to bottom of the 100,000 database >>>>> with >>>>>>> the view fully expanded. I found that the more columns one shows, the >>>>>>> more >>>>>>> sluggish the scrolling (as one might expect). However, this is true >>>>> with >>>>>>> all of the standard columns. The proposed columns did not slow the >>>>>>> scrolling down any more than any other column (although gender might >>>>> be >>>>>>> slightly faster to render, and spouse, birth, and death dates might >>>>> be >>>>>>> slightly slower). Of course, this is under the user's control, so >>>>> they >>>>>>> can >>>>>>> adjust as they see fit. >>>>>>> >>>>>>> I think that these data points suggests that there is no inherent >>>>> reason >>>>>>> why we might want to prevent the user from being able to display this >>>>>>> data >>>>>>> in the people view. I have no desire to change the tables. I leave >>>>> the >>>>>>> filters for later, but I do agree with Benny that these will be >>>>> useful. >>>>>>> Given that these don't have significant negative impact, require very >>>>>>> little code (low maintenance), and could be quite useful to people, >>>>> this >>>>>>> leaves some of my original questions: >>>>>>> >>>>>>> 1) Don and Richard both indicated that the model/view code may change >>>>>>> soon. These two columns are pretty simple code, so shouldn't have a >>>>>>> large >>>>>>> code impact. Should we add them to 2.2 and/or >>>>>>> 2.3, or wait till the new model/view is implemented? >>>>>>> >>>>>>> 2) The "Age on Date" requires a date. I have an idea on this that has >>>>>>> little impact on code or interface. >>>>>>> >>>>>>> 3) Are there other age-related values that you would like to see in >>>>> the >>>>>>> person view, or in other places? >>>>>>> >>>>>>> The next step, I'll provide a patch and you can try this out. >>>>>>> >>>>>>> As always, thanks for any and all feedback, >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>>> Storing a calculated value in a database is also highly unlikely. It >>>>>>>> could cause >>>>>>>> disaster for the saving time of a person record, as well as problems >>>>>>> when > the >>>>>>>> algorithm is improved after an upgrade, ... >>>>>>>> >>>>>>>> A filter has the disadvantage as you say that you do not see why it >>>>>>>> returns the >>>>>>>> data you request. Like if you do name search Jon, and you get Jan >>>>>>>> returned. You >>>>>>>> can deduce that Jan has an alternate name Jon, but you do not see >>>>> it. >>>>>>>> This is a general issue with filters, a general solution for this >>>>>>> problem > not >>>>>>>> requiring the addition of columns would be most welcome. >>>>>>>> >>>>>>>> Benny >>>>> >>>>> ------------------------------------------------------------------------- >>>>> Take Surveys. Earn Cash. Influence the Future of IT >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>>>> your >>>>> opinions on IT & business topics through brief surveys-and earn cash >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>>> _______________________________________________ >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> ------------------------------------------------------------------------- >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>>> your >>>> opinions on IT & business topics through brief surveys-and earn cash >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>> >>> -- >>> Douglas S. Blank >>> Associate Professor, Bryn Mawr College >>> http://cs.brynmawr.edu/~dblank/ >>> Office: 610 526 601 >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |