Prev: Could this unclosed() byteArrayInputStream cause high Heap usage ?
Next: large XML files
From: luc peuvrier on 7 Feb 2010 05:37
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.
From: Lew on 7 Feb 2010 11:30
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.

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
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
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?

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


From: Lew on 7 Feb 2010 12:00
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. 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.

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, that it imposes a lot of data-storage-aware code on core
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.

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, ...

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.

Feel free to answer point by point with substantiable arguments.

--
Lew
From: Arne Vajhøj on 7 Feb 2010 17:01
On 07-02-2010 05:37, luc peuvrier wrote:
> what do you think of
> http://joafip.sourceforge.net/database/dbvsjoafip.html

I think the author is spamming to much in this group ....

Arne
From: luc peuvrier on 7 Feb 2010 17:17
On Feb 7, 11:01 pm, Arne Vajhøj <a...(a)vajhoej.dk> wrote:
> On 07-02-2010 05:37, luc peuvrier wrote:
>
> > what do you think of
> >http://joafip.sourceforge.net/database/dbvsjoafip.html
>
> I think the author is spamming to much in this group ....
>
> Arne

May be announce joafip twice is two much.
I made an error the second announce was for comp.­lang.­java.­
databases
really sorry.
Luc
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Could this unclosed() byteArrayInputStream cause high Heap usage ?
Next: large XML files