On Sat Mar 22 2014 Sriram Karra wrote: > Agreed. The alist should take a field name - can be one of the > standard field names, or a user defined notes field key and value > being can either be a set of defined symbols (like merge, > keep-older, keep-newer) or if it's a function it will be invoked > with the values from the two records and whatever the function > returns will be used for the merged record.
`Alist' means that there is a list of pairs (key . value), In this case the keys should be field names like `address', `mail', `notes', etc. The corresponding values should be the recipes for merging the fields. This should be more transparent than one function for the whole record. A recipe like keep-older or keep-newer will be difficult to implement, as there is only a date associated with the full record, but not with individual fields. Well, this would be up to the user to decide what to do. But then it would be good if the functions implementing the merge recipe for a particular field could access the full records, so that merging field A may depend on the respective values of field B. Roland ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
