object relational database versus "inteligent" serialization
in [Java Programming]
|
From: Tom Anderson on 7 Feb 2010 17:31 On Sun, 7 Feb 2010, Lew wrote: > I've been working with databases, including both relational and > network-model systems, for nigh thirty years, and attempts to create > "object-oriented" data systems since "object-oriented" became a > buzzword. None of the OODBs or ORMs were worth a damn until Hibernate, > and since then, JPA rolled out. Did you ever use GemStone/J? I haven't, but it's been going since the bronze age, and has a good reputation. tom -- Dreams are not covered by any laws. They can be about anything. -- Cmdr Zorg
From: Tom Anderson on 7 Feb 2010 17:36 On Sun, 7 Feb 2010, Lew wrote: > Tom Anderson challenged you to show how your project differs from JDO, > the failed predecessor to JPA. I didn't actually do that - i observed that it was the same. I wasn't expecting the OP to disagree! I wouldn't describe JDO as failed, either. It was a technical success, but just a commercial failure, IMHO because there's so much inertia around RDBMSs. Nonetheless, i stand by my assertion that joafip is providing the same service as a JDO implementation, which i think is the point you were making use of here. > Now you're back again, starting an entirely new thread on the exact same > topic, and somehow I suspect you will once again refuse to engage > directly in the challenge of showing why we should pay any attention > whatsoever. Maybe we should set him up with that guy who's reinvented CORBA, and isn't interested in discussing the fact either. Between them, they've reinvented a good chunk of the J2EE stack; we just need someone to reinvent servlets and we've got the whole shooting match. tom -- Dreams are not covered by any laws. They can be about anything. -- Cmdr Zorg
From: luc peuvrier on 7 Feb 2010 17:36 On Feb 7, 5:30 pm, Lew <l...(a)lewscanon.com> wrote: > On 2/7/2010 5:37 AM, luc peuvrier wrote: > > > what do you think of > >http://joafip.sourceforge.net/database/dbvsjoafip.html > > > I created joafip to manage more objects than memory can contains. > > I can also be use to persist data model. > > There is no query language, all is done using object navigation: > > relations between class are coded in the classes. > > You never answered the questions and comments from people the last time > you spammed for this project. > > Except to write me privately and deny that you're a spammer, something > to which this latest post gives the lie. > I answered about this to Arne Vajhøj, bad place, sorry. > Oh, you responded, but your responses didn't address the points. For > example, Arved Sandstrom that "persistence providers like EclipseLink > have put a lot of effort into doing 'intelligent' serialization as > described above." You answered that "[t]he joafip goal was to write a > full object data model without take care of memory amount, the object > graph is derecitly backend to file." How does that address the point > that your product doesn't add value compared to, say, EclipseLink? I Yes, I can not compare to EclipseLink because I do not know it ! > don't even understand what you were trying to say there, much less how > it distinguishes your project. > > Tom Anderson challenged you to show how your project differs from JDO, > the failed predecessor to JPA. You threw the ball back in his court, > "I will be happy you compare the JOAFIP and JDO facade." When I pointed > out that it's your job to make the comparison for us, your only response I notice that you are waiting for. I am happy: it is a good start for discussion. > was to (falsely) deny that you're a spammer. You completely ducked > tom's point. What's the matter, afraid your project will suffer for the > comparison? Suffer ? yes I want ... I explain: I do not pretend that joafip will take the place of all these wonderful solutions persistence (which I do not control, that is not the case for replier: Welcome ) > > There is nothing in any description of your project that shows it to > have any advantage whatsoever over any other object-storage or > object-relational-mapping framework. Maybe because your project isn't > offering any such advantage? I'm willing to accept that it might, but > your refusal to delineate any is rather telling, I'm afraid. > > Now you're back again, starting an entirely new thread on the exact same > topic, and somehow I suspect you will once again refuse to engage > directly in the challenge of showing why we should pay any attention > whatsoever. > > You can change that impression and prove me wrong, of course. That is, > if you have anything substantive to say. > > -- > Lew your answer has the merit of being clear Thank you again
From: luc peuvrier on 7 Feb 2010 18:50 On Feb 7, 6:00 pm, Lew <l...(a)lewscanon.com> wrote: > On 2/7/2010 5:37 AM, luc peuvrier wrote: > > > what do you think of > >http://joafip.sourceforge.net/database/dbvsjoafip.html > > > I created joafip to manage more objects than memory can contains. > > I can also be use to persist data model. > > There is no query language, all is done using object navigation: > > relations between class are coded in the classes. > > I get suspicious of anyone's code when the examples, such as the one > that leaps out at one from your link, contain major flaws from both a > coding and a pedagogical perspective. Your "item entity" example has a > constructor that calls 'super()' although the type descends directly > from 'Object' and 'super()' is called regardless. Java good practise say to call super, and PMD I use warning if missing >It uses 'float' to > represent a monetary amount. One might argue that it's "just" an > example, but that lack of attention to detail in the visible example > makes one worry whether you pay enough attention in the library code. Logic ! If I use a float for a monetary amount, who can imagine I can write a quality code ! just between us, after 30 years of programming I have never handled monetary data: surprise, right? I am really happy to learn than float is not proper. > > The far more serious flaws with the joafip library are that it recreates > the ancient network database model, where all the data relations are > predefined, Yes,but: relations between object are coded in class, a fixed data model. I do not know that serialize this fixed data model is the ancient network database model... > that it imposes a lot of data-storage-aware code on core that is not the case with joafip: the data model is managed as a graph replicated on a file. This is the most important joafip feature. > logic that should be at least largely unaware of that aspect, that it > doesn't support any kind of ad hoc query mechanism that I can see, and > that it doesn't do any better at supporting an object model than > existing, robust, flexible solutions like every JPA implementation. Yes,but: I believe your right at a big database point of view and flexibility needs. In project trigered joafip, we have a data model easy to code using collections, but I think more complex to code using request feature, may be not, but so easy to code it in java. > I've been working with databases, including both relational and > network-model systems, for nigh thirty years, and attempts to create > "object-oriented" data systems since "object-oriented" became a > buzzword. None of the OODBs or ORMs were worth a damn until Hibernate, > and since then, JPA rolled out. > Now you come along, re-inventing the > wheel but ignoring things like suspension, springs, shock absorbers, > bearing grease, ... > wheel bycyclette against wheel space shuttle. This is not comparable. May be in the example I should warn that this is a limited solution. And gives link to very large brothers you mentionned. in short, joafip as a database solution is under ancle of existing framework, I confirm, but why a truck to move an eggs ? > It is obvious that a lot of work went into it, and within the severe > limitations of its programming model it seems rather complete. It's > just that I can write cleaner code, with more robust data interaction > and safety, and more convenient management of the underlying data > persistence, with more flexibility going forward, and the comfort of > knowing there's a large support framework, and I will bet dollars to > doughnuts far better performance especially under heavy or heavily > concurrent load, by going with a JPA solution like Hibernate, > TopLink/EclipseLink or OpenJPA. > doughnuts caviar ? may be, measurement needed. > > Feel free to answer point by point with substantiable arguments. > > -- > Lew Thank you to do the comparison with existing persistence solutions, even if you wanted I do it for you. And also thank you to share your network database knoledge. Luc Peuvrier
From: Arne Vajhøj on 7 Feb 2010 22:16
On 07-02-2010 17:36, Tom Anderson wrote: > On Sun, 7 Feb 2010, Lew wrote: >> Tom Anderson challenged you to show how your project differs from JDO, >> the failed predecessor to JPA. > > I didn't actually do that - i observed that it was the same. I wasn't > expecting the OP to disagree! > > I wouldn't describe JDO as failed, either. It was a technical success, > but just a commercial failure, IMHO because there's so much inertia > around RDBMSs. Hm. Most actual JDO usage were as an ORM for a RDBMS. Arne |