E-mail client <from> issue and this post never made it, so I'm forwarding my response again.
---------------------------------------- Glen Batchelor IT Director/CIO/CTO All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: [email protected] Web: http://www.all-spec.com Blog: http://blog.all-spec.com ---------------------------------------- > -----Original Message----- > From: Glen Batchelor [mailto:[email protected]] > Sent: Friday, December 10, 2010 2:38 PM > To: 'U2 Users List' > Subject: RE: [U2] Sparse array population in Pick > > > You can also store the metadata outside of the data item in another item > using a standardized item naming structure. If a specific file contains > the same types of data formats then you can store a global default in a > locally or globally unique key. When creating new records the default > layout is pulled up. This allows you more formatting and storage > flexibility, IMO, but always requires two normal reads instead of one to > obtain the data and metadata. In the case of a new data item, 2 reads will > still be required. One to determine the item doesn't exist and a second to > read the default meta so a new item can be created. > > CARS > $$METADEFAULT > 001 Make > 002 Model > 003 Age > $$META.TAGS1052 > 001 Make > 002 Model > 003 Age > 004 Comments > TAGS1052 > 001 Chrysler > 002 LeBaron > 003 2558 D (2558 days) > 004 This item is a non-default data test > > If you required multiple formats in the same data file, then that's OK. > You can always store additional non-standard formats in additional > $$METADEFAULT.XXXX items. XXXX would be the format number and you can > store descriptions in the dictionary regarding what the various XXXX > format codes are meant to be used for. Another, more compact, option is to > just store the description of the metadata in attribute 001 and shift the > data down one attribute. > > CARS > $$METADEFAULT > 001 Normal inventory filings for autos > 002 Make > 003 Model > 004 Age > $$METADEFAULT.0001 > 001 Collision inventory related filings for autos > 002 Incident Date > 003 Make > 004 Model > 005 Age > 006 Insurer > 007 Policy Number > 008 Notes > $$META.TAGS1052 > 001 TAGS1052 Created on 10/12/2010 by GB > 002 Make > 003 Model > 004 Age > 005 Comments > TAGS1052 > 001 Chrysler > 002 LeBaron > 003 2558 D (2558 days) > 004 This item is a non-default data test > > I could make up more sample data, but I hope that's enough to understand > to structures. > > Regards, > > ---------------------------------------- > Glen Batchelor > IT Director/CIO/CTO > All-Spec Industries > phone: (910) 332-0424 > fax: (910) 763-5664 > E-mail: [email protected] > Web: http://www.all-spec.com > Blog: http://blog.all-spec.com > ---------------------------------------- > > -----Original Message----- > > From: [email protected] [mailto:u2-users- > > [email protected]] On Behalf Of Bill Brutzman > > Sent: Friday, December 10, 2010 10:56 AM > > To: U2 Users List > > Subject: Re: [U2] Sparse array population in Pick > > > > Consider replacing "age" with "year" or "purchase date". > > > > --Bill > > > > -----Original Message----- > > From: [email protected] [mailto:u2-users- > > [email protected]] On Behalf Of [email protected] > > Sent: Thursday, December 09, 2010 5:10 PM > > To: [email protected] > > Subject: [U2] Sparse array population in Pick > > > > Years ago I had written a system, far predating XML, where the element- > > tags were unpredictable. Essentially the user was allowed to create any > > tags they wished, and any number of tags they wished, attached to > another > > item. > > > > Each tag had an associated value. So far example > > Zip Code = 95062 > > > > You could not however predict what tags a person would use, they were > all > > free-form and user-supplied, but you still had to store the tag with > their > > associated value. > > > > At the time I developed two ideas for how to do this in a Pick item > > > > TAGS1052 > > 001 Make = Chrysler > > 002 Model = LeBaron > > 003 Age = 7 years and 3 days > > > > TAGS1052 > > 001 Make]Model]Age > > 002 Chrysler > > 003 LeBaron > > 004 7 years and 3 days > > > > The first model is clear. Anyone with no programming background at all, > > can easily understand it, and also easily edit it. It suffers from > > requiring more elaborate programming than the second model, as you have > to > > parse every element. > > > > The second model is not quite as clear. You determine the attibute > > position of the "value" by locate the tag in attribute 1 and then adding > 1 > > to it. > > That gives you the attribute number where the value lives. Alternately > > you could simply pre-fill attribute 1 with an initial null to push > > everything forward 1 place, then you wouldn't have to add 1 after your > > locate. > > > > Comments? Critiques? Nasty cat-calls and grimaces? > > > > Will Johnson > > > > > > _______________________________________________ > > U2-Users mailing list > > [email protected] > > http://listserver.u2ug.org/mailman/listinfo/u2-users > > _______________________________________________ > > U2-Users mailing list > > [email protected] > > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
