One of the main differences between OFBiz and other kinds data-centric frameworks is that OFBiz works directly on an Entity-Relational model, instead of adding a layer of Object-Relational mapping.
What I think you are describing is essentially a DAO architecture. OFBiz fundamentally does not use an Object mapping for the database. It uses a Map, whose attributes represent a projection of the fields of a relation, and whose values represent the data of a relational record. GenericValue is a specialization of Map that adds some DAO semantics to the map and some useful characteristics such as identifying PK fields, but it's fundamentally just a Map. I think your expression "pyramid of objects" refers to a persistent Object that contains collections of other persistent Objects, which is generally the ORM way of looking at the problem. OFBiz purposely avoids the ORM concept, and instead takes a much more direct approach to using the Entity-Relational concept. Your existing model may be too large or complex to justify much change. In that case I might recommend that you create a layer, using services, that presents this data as service result Maps, build services that can extract the SQL connection from the Delegator, and then you could possibly use your existing code. Ideally, you would have a look at your schema, express that schema as entitymodel.xml, then identify and separate any behavior from your data binding layer, and express that behavior as services. But first you will need to stop thinking of the database as an "Object store." On Fri, Dec 10, 2010 at 5:53 AM, David van der Staak <[email protected]> wrote: > And ofcourse I make a huge mistake in my first post on this list by > forgetting to change the subject ..... attempt 2! > > Hi all, > > I've been trying to merge our existing project to one based on OfBIZ. I've > had a bit of succes thus far, but I've hit a snag. > > We used to run on a MySQL. I build a Database.class which had a few easy to > use methods, which you could hand an id to retrieve an object or hand an > object for storage. The objects themself also have a store method, which was > shorthand for calling the Database.store() method yourself. > > A problem I'm running into right now is how to store and retrieve a pyramid > of objects. I used to be able to call Database.get(id) which would give me an > object, which was a child of SObject, and have a specialized method which > would also take a class argument. The main problem is in the first retrieval > method, the generic one. All of the find methods I can see require me to use > an entity name, but I can't be sure which entity name I should use, unless I > use at least one more call to the database as I would have to store yet > another piece of information in a seperate entity. > > Is there an easier way then having to store yet another entity, and do 2 > finds when I need to recreate an object? > > Second point: Is there a method which can create an object for me? Do I need > to subclass a specific class or use a specific method? All that I have found > thus far is that the find methods return a genericValue. I suppose I could > get all the values and stick them into my own object, but I'm not sure that's > the proper way of doing it. > > Thanks for the time, help and patience. > > David van der Staak -- James McGill Phoenix AZ
