Except for there not currently being a ProductRole entity, why wouldn't the publisher be handled as a party?
--- David E Jones <[EMAIL PROTECTED]> wrote: > > That's a little bit different then... > > What you probably need/want is some code to take in > the incoming ONIX > files and map the information to existing OFBiz > entities rather than > creating new ones. > > As you're doing the mapping you'll get into the > issue you brought up > here about what should go where. Different things > will most likely be > best handled in different ways. For example, the > "publisher" would be > handled well by a ProductFeature, but the title and > ISBN would not as > they are unique to each book. Those could be put > into ProductContent > records (with new ProductContentTypes) and handled > with existing > code, or perhaps even just added as fields to the > Product entity, and > then only small changes would be needed in the > ProductSearch code (or > no changes... it's been a while since I wrote it so > I don't remember > exactly). > > In any case, I think you'll find pretty flexible and > efficient > performing search capabilities in the ProductSearch > stuff. Make sure > you're looking at a moderately recent version of > OFBiz (ie not one of > the ancient releases, like 3.0.0 or something). > > -David > > > On Aug 8, 2006, at 12:43 AM, Iain Fogg wrote: > > > David, > > > > Basically I'm looking to augment the standard > OFBiz functionality > > with functionality specifically required in the > book selling > > business. As an absolute minimum, I need to be > able to periodically > > refresh the OFBiz product and supplier data with a > subset of the > > ONIX data (new titles, price changes, supplier > info, etc). I also > > want to look at ways of providing a richer set of > search options > > specific to the book trade (eg, title, publisher, > ISBN, etc), and > > to have all of the ONIX data available for > back-office (and > > sometimes front-of-house) enquiries. > > > > I've seen it suggested that one of the ways to > provide richer > > content in the OFBiz Product database is to use > the Feature > > mechanism. I've played around with this a little > bit, and it might > > work, but I'd need to be convinced about > performance and > > maintainability. The ONIX dataset can contain > hundreds of thousands > > of records, and modelling these with the OFBiz > Feature feature > > seems a bit clumsy. I'm not sure what the impact > would be on search > > queries. > > > > I'm still exploring my requirements, and at this > stage about the > > only thing I know for sure is that I need to synch > ONIX data with > > OFBiz to ensure OFBiz is using up-to-date info. > Probably the other > > thing I know for sure is that I need richer search > options, and > > response needs to be reasonable. > > > > At the end of the day, one of the things I need to > work out is how > > to "integrate" (and I use the term loosely), ONIX > and OFBiz. > > > > Cheers, Iain > > > > > > David E. Jones wrote: > > > >> > >> Is the intent to map it to the OFBiz data model > or services? I'm > >> guessing that's not the case if you're trying to > create entities > >> to represent it. > >> > >> If you're trying to create a data model for an > XML Schema and not > >> mapping it to an existing data model, then you'll > have to design > >> a data model to match it. XML is an hierarchical > data structure > >> which is very different from a relational > (table-based) one. Some > >> design will have to be done to decide how to > structure things > >> because there are no natural equivalencies. > There are, of course, > >> some common patterns for dealing with > hierarchical and other > >> structures in SQL, but doing an effective > mapping requires more > >> of an understanding of the data model so that > the same data can > >> be captured in both places and this is very > difficult to > >> automate. You might find some commercial tools > that give you a > >> good first pass though... ie to go from XSD to > SQL DDL. > >> > >> -David > >> > >> > >> On Aug 7, 2006, at 6:51 PM, Iain Fogg wrote: > >> > >>> Chris, > >>> > >>> Good question, and this probably exposes my > ignorance of XST. > >>> Maybe it's not the right technology. Maybe I > need to find a tool > >>> that can translate from XSD -> SQL. Then it > would be > >>> straightforward to map the relational table > defs to the OFBiz > >>> entity def. My small brain can't get round the > mapping of the > >>> hierarchical XML Schema to a relational one - > at least not given > >>> it's size. Maybe when I was younger :-) > >>> > >>> In case anyone is interested, the schema I want > to map is the > >>> ONIX schema (used in the book trade). > >>> > >>> Cheers, Iain > >>> > >>> Chris Howe wrote: > >>> > >>>> Correct me if I'm wrong, but wouldn't you need > to know > >>>> what the source elements are in order to make > an XST > >>>> to entity def? Absent knowing the structure of > your > >>>> source it wouldn't matter what someone else's > XST > >>>> looks like, it wouldn't work with yours. > >>>> > >>>> --- Iain Fogg <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> That's my question...has anyone already buit > an XST > >>>>> to do the conversion to OFBiz Entity defs? > >>>>> > >>>>> BJ Freeman wrote: > >>>>> > >>>>> > >>>>>> the XSD defines the layout. > >>>>>> the XML is where the Entities definitions > are. > >>>>>> you can try using an XST file to convert. > >>>>>> > >>>>>> Iain Fogg sent the following on 8/7/2006 7:53 > AM: > >>>>>> > >>>>>> > >>>>>>> I have a slightly complicated XML Schema > (.xsd) > >>>>>>> > >>>>> that I would like to > >>>>> > >>>>>>> import into OFBiz. > >>>>>>> > >>>>>>> Has anyone written a tool to convert XML > schemas > >>>>>>> > >>>>> into OFBiz entity > >>>>> > >>>>>>> definitions? > === message truncated ===
