Menu
▾
▴
Re: [Gramps-devel] [Gramps-users] Status report on Gramps-Connect
|
From: jerome <rom...@ya...> - 2012-08-16 05:55:18
|
It sounds good! Note, can we imagine a related feature: ability to import (merge) only one table (type of primary object)? Having a top level filter (factory, hierarchical level, etc ...), then like 'Export screen...' feature from menu into list views, to be able to import/dump a specific table without relation with others primary objects! Why to do that? *Most part of time this could be very useful when one has planned a migration from a closed file format to something more flexible like gramps[1]. *There is a lot of simple tables (places[2], events[3], sources/citations[4], persons, families, notes/transcriptions) dedicated to genealogy (3rd party indexes, publications, sql tables, etc ...). To have a quick way to handle content without new seizure might be productive (and consistent). As you said, this may be more difficult to merge without an unique ID. Anyway, I guess this is also one limitation on current Gramps CSV import[5]. Users know that and I guess that they have already tested CSV import. If we go further, with your code, it should be also possible to test consistency of the imported records, right? ie. syntax, type of imported data according to Gramps DB model. [1] http://www.cohsoft.com.au/tmg2gramps/ [2] http://www.gramps-project.org/wiki/index.php?title=Place_database [3] http://www.gramps-project.org/wiki/index.php?title=Events_manager [4] http://www.gramps-project.org/wiki/index.php?title=Tellico [5] http://www.gramps-project.org/wiki/index.php?title=Gramps_3.4_Wiki_Manual_-_Manage_Family_Trees:_CSV_Import_and_Export Thanks! Jérôme --- En date de : Mer 15.8.12, Doug Blank <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] [Gramps-users] Status report on Gramps-Connect > À: "Benny Malengier" <ben...@gm...> > Cc: gra...@li..., "Jiri Kastner" <cz1...@gm...> > Date: Mercredi 15 août 2012, 15h56 > On Wed, Aug 15, 2012 at 9:44 AM, > Benny Malengier > <ben...@gm...> > wrote: > > > > > > 2012/8/15 Doug Blank <dou...@gm...> > >> > >> On Tue, Aug 14, 2012 at 7:42 AM, Doug Blank <dou...@gm...> > wrote: > >> > >> [snip] > >> > >> >> About implementation. I would expect it to > be a dictionary of > >> >> dictionaries, > >> >> and on lowest level strings or integer, > but sometimes it is list, > >> >> because it > >> >> has to be ordered. > >> >> Well, I don't like that "citation_list": > CitationBase.to_struct(self) > >> >> is a > >> >> list, but other to_structs are dicts > (wrong doc of the method there by > >> >> the > >> >> way). I think these objects better have no > to_struct method, and you > >> >> just > >> >> write the attribute you need. > >> >> > >> >> to_struct being list is counterintuitive. > >> > >> I looked into making the output always be the same > type (considered > >> dicts, orderdicts, and namedtuples) but I think it > is better to see > >> this analogous to Object.serialize(). > Object.serialize() will give you > >> a variety of types depending on the Object (list, > tuple, int, bool, > >> and even dict). > >> > >> It would be handy to mark some of these items with > additional > >> metadata. For example, marking a handle as such > indicates that it is a > >> dependency. But I'll look into other ways to mark > it... > > > > > > But why do these Base objects require a to_struct? Just > obtain the single > > attribute you require. > > The fact that it is a list, indicates to me you don't > need to_struct. > > I guess for the same reason that Base objects have a > serialize(): each > object takes care of its own representation. I think that > this will > make it easier to maintain and develop. > > -Doug > > > Benny > > > > > >> > >> > >> -Doug > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |