QRM stands for "Qi4j-to-Relational Mapping" for those that has missed the acronym previously.
On Tue, Aug 18, 2009 at 2:18 AM, Alex Shneyderman<[email protected]> wrote: >> >> We need to get the libraries and extensions touched up as well, which mostly >> means QRM. Niclas has some ideas on how to do that in a minimalistic >> fashion, but if anyone has experience with OR mapping and wants to work on >> it, it's an open field (Niclas, right?). If we can't get them updated fairly >> shortly we will release Qi4j 1.0 Core separately from everything else, just >> to get it out. > > QRM is one piece of work. > > The easiest thing to do at the moment is to serialize entities as JSON > and store serialized text in some table - reusing > org.qi4j.entitystore.map.MapEntityStore. That of course looses all > the wanted benefits of some folks (which is understandable) ... me > included. Nah, that is an "SqlEntityStore" (no idea why bother with that though), where there is one table with a couple of columns; Identity, LastModified, Version, Data or so.... > Solution that was there before sort of smells as user has to go and do > mapping on his own a task that should not be necessary as model > information is available, so user should provide only what's missing > or default is not what he wants. What I have in mind is fairly simple 1.0 approach; 1. The use-case is that the SQL schema and data exists, and is possibly read/modified by other applications. 2. The data model in Qi4j must match the SQL schema. 3. One Entity type per SQL table. 4. One Property or Association for each column. 5. Support for 1..n associations via reverse reference (the n entity has a column pointing to the "1" entity), 6. Support for m..n associations via mapping table. 7. Support to use SQL views and possibly stored procedures. 8. As little (mapping) configuration as possible, preferably convention for everything. This won't allow complex mappings in a 'free-for-all' way, and requires the Qi4j model to adapt to the SQL schema. > Solution that would be an ultimate solution (the OR mapping way) is a > lot of work. What is your time-line there? I agree that it is a lot of work (compared to a key-value store), and when use-cases starts pouring in some time down the line, there will be an endless stream of feature requests beyond my suggested package. But I think the above can be coded within 100 man-hours, with the help of iBatis or similar tools. That would only make it feasible to have ready by early Sept if someone could put in a near fulltime effort, which I don't think is reasonable to expect. So, let's say that we target Core 1.0 by beginning of Sept and Libraries 1.0 in mid-Sep and Extensions 1.0 by early October. I need to spend a fair amount on Core 1.0 release as well as preparing for a "Qi4j Persistence" presentation at JavaZone/Oslo 9-10 Sept, but I still have time to help out on a QRM effort with guidance and key bits if someone take on the larger portion of details and tests. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
