object relational database versus "inteligent" serialization

[Lew]

lew says...

What if the new parent-class has a non-empty constructor that needs to
be called with super()?

You mean 'super( someArg )', not 'super()'. Then it would not be the scenario
I was describing. Furthermore, having the call to 'super()' before that
refactoring is not any better. Either way, you have to add the newly-required
calls to 'super( someArg )' to the extending classes. My point about the
uselessness of a call to 'super()' remains unaffected.

However, that particular scenario you describe would be irresponsible. Once a
class is released into the wild with a public API, such as the existence of a
no-arg constructor, you remove from that API at grave peril. It is a very
rude thing to destroy existing code when you refactor. Once you've committed
to an API, and that includes methods, constructors and serialization
dependencies, you have to be responsible for that commitment.

When following best practices, the scenario you describe will not arise, and
even did it, having had calls to 'super()' provides not a jot of protection.
The explicit call to 'super()' is just useless, bureaucratic anal retention.

 

[Tom Anderson]

There's nothing wrong with that. In future someone could change the
extended class and need not worry about the constructors.

That's also the case without the explicit constructor call. Just to be
completely clear, this code:

class Foo {
public Foo() {
}
}

And this:

class Foo {
public Foo() {
super();
}
}

Do *exactly* the same thing, and compile to *exactly* the same bytecode.
Adding the explicit super() adds nothing.

tom

 

[Tom Anderson]

What if the new parent-class has a non-empty constructor that needs to
be called with super()?

You've misunderstood. Go back and read what the JLS has to say about
superclass constructor invocation.

tom

 

[luc peuvrier]

AHS said:

Let me ask what I believe is a relevant question, Luc: have you
used either Hibernate or Toplink Essentials/EclipseLink, with JPA
1.0, to any reasonable extent? By "reasonable" I mean a
non-trivial application that
requires a broad mix of persistence design decisions.

I never use ORM solution.

AHS said:

I think you can see why I ask the question.

Luc:
Yes, it seems stupid to write a library whithout knowing existing
solutions ! in fact, yes, it is stupid, but not stupid to write
joafip, joafip is not an ORM, it is an object persistence in a file
library.

AHS said:

If you haven't used JPA with
either, isn't writing something new a misguided labour?

Luc:
A really exiting labour (for me)

AHS said:

If you
have used
either or both persistence providers, why exactly were they so
deficient? I'm curious.

Luc:
This is a good question: why for develop joafip ?
Because the problem it been ask me to solve was:
- do not use the database of the application because too much busy to
integrate data.
- cache the data model in a file
- avoid spend execution time in ORM mechanic
And the data entity to store is quite complex at relational object
point of view.
joafip concept is simple: a serialization in file that only write
changes and use lazy load to avoid reload all in memory.

AHS said:

Or what about iBatis, which I'm personally quite fond of? Point
being,
and this is just my opinion, you shouldn't waste your time solving
nonexistent problems.

Luc:
because iBatis is an ORM front of a database.
the problem to solve exist.

AHS said:

And you wouldn't be the first person
announcing
new persistence frameworks on this NG...
Luc:

AHS said:

to me it seems like you
guys
would be performing a greater service to the community by tackling
real
problems.

Luc:
it seems that the problem I had to solve is not common.
thank you for inviting me to be more useful.
May be this NG is not the right place for my subject

 

[Lew]

Yes, it seems stupid to write a library whithout knowing existing
solutions ! in fact, yes, it is stupid, but not stupid to write
joafip, joafip is not an ORM, it is an object persistence in a file
library.

"ORM" is a means to the same end that joafip seeks. That joafip is not an ORM
is not relevant. That it and ORM both handle persistence of an object model
is relevant. Thus, joafip has to compete with ORM solutions, among others.

AHS said:

Luc:
This is a good question: why for develop joafip ?
Because the problem it been ask me to solve was:
- do not use the database of the application because too much busy to
integrate data.

Who or what was too busy? People or machines?

Modern ORM solutions can provide no-effort persistence for the types of simple
problems joafip purports to handle. Discounting the effort of creating a
custom solution like joafip, the two seem not to differ much in that regard.

- cache the data model in a file

Why a file? How is that better than in a database?

I can certainly see how it'd be better to "cache" the data in a database than
a file, but the argument the other way eludes me.

- avoid spend execution time in ORM mechanic

That means you measured how much execution time is spent "in ORM mechanic"
and in your persistence solution, and you have hard numbers as to the advantage.

What are they?

And the data entity to store is quite complex at relational object
point of view.

Could you explain that in more detail? Using JPA, the storage is only complex
if the entity model is complex. For the most part, the JPA framework can
deliver the data model to back the object model without programmer effort.
Where does that mechanism break down? How does joafip do it better?

Based on the sample code on the project site, the joafip version of code is no
less complex than an equivalent JPA solution would be.

joafip concept is simple: a serialization in file that only write
changes and use lazy load to avoid reload all in memory.

Again, that's no different from what existing, mature solutions do.

AHS said:

Luc:
because iBatis is an ORM front of a database.
the problem to solve exist.

That does not follow. You are assuming your conclusion, that an ORM in front
of a database is a problem. It is not.

 

[Arne Vajhøj]

Luc:
float is an approximate numeric datatype, as defined by ANSI
standards.
http://stackoverflow.com/questions/285680/representing-monetary-values-in-java:
"Martin Fowler recommends the implementation of a dedicated Money
class to represent currency amounts, and that also implements rules
for currency conversion."

That is one option.

java.math.BigDecimal may be good enough for many cases.

Arne

 

[Arne Vajhøj]

I never use ORM solution.

Maybe not.

But I would guess that 80-90% of persistence in Java
in real apps are done using some type of ORM.

So natural that is what a persistence solution will be compared
to.

Arne

 

[luc peuvrier]

"ORM" is a means to the same end that joafip seeks.  That joafip is not an ORM
is not relevant.  That it and ORM both handle persistence of an object model
is relevant.  Thus, joafip has to compete with ORM solutions, among others.

AHS said:


Who or what was too busy?  People or machines?

Luc:
machine was busy.

Modern ORM solutions can provide no-effort persistence for the types of simple
problems joafip purports to handle.  Discounting the effort of creating a
custom solution like joafip, the two seem not to differ much in that regard.

Luc:
- Yes it is, I believe in ORM solutions according to description I
read and according to your remarks.
- The two solution differs: ORM have database as bakend layer, joafip
persist an object graph in a file. joafip is between a "classic"
serialisation ( native serialization, xml encoder/decoder, xstream ..)
and high level ORM solutions.

Why a file?  How is that better than in a database?

Luc:

I had to obey to my project manager and architect.
I understood they want to reduce stacking layer between the objets in
memory and the bytes in the file.

I can certainly see how it'd be better to "cache" the data in a database than
a file, but the argument the other way eludes me.

- avoid spend execution time in ORM mechanic

That means you measured how much execution time is spent "in ORM mechanic"
and in your persistence solution, and you have hard numbers as to the advantage.

What are they?

Luc:
A team member validate the storage performance using joafip in our
application context.
According to your question, I should compare with ORM+database
solutions.

Could you explain that in more detail?  Using JPA, the storage is only complex
if the entity model is complex.  For the most part, the JPA framework can
deliver the data model to back the object model without programmer effort..
Where does that mechanism break down?  How does joafip do it better?

Based on the sample code on the project site, the joafip version of code is no
less complex than an equivalent JPA solution would be.


Again, that's no different from what existing, mature solutions do.

Luc:
The only difference is that ORM store object fields in database table
record. joafip write object state in a file binary data record.

AHS said:


That does not follow.  You are assuming your conclusion, that an ORM in front
of a database is a problem.  It is not.

Luc:
I never said "is a problem". I repeat, I beleive in ORM solution
according that I learn on it and according to your attestation.
All things can be a problem or solution: each solutions have good and
bad point according to a criteria list.
I do not want joafip be used in context where it exist best solutions.

In fact, to be agnostic, I have to works on a list describing wich for
joafip is good for and wich for is bad for.

Thank for your help

 

[luc peuvrier]

Maybe not.

But I would guess that 80-90% of persistence in Java
in real apps are done using some type of ORM.

So natural that is what a persistence solution will be compared
to.

Arne

object persistence is a broad topic:
starting from a simple serialization in a file up to storing/
retreiving in multiple database dispatch in multiple data center.

is the topic "object relational database versus intelligent
serialization" is appropriate ?
According to the definition of "database" word, I think yes.
May be somebody can argument that it is not.

Luc

 

[Arved Sandstrom]

On 8 fév, 11:31, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

Luc:
it seems that the problem I had to solve is not common.
thank you for inviting me to be more useful.
May be this NG is not the right place for my subject

This NG is an appropriate forum I think. It's not specialized but many
of us do regularly use persistence solutions, and not all of them have
been ORMs either. There are OODBMSs, for example, not just RDBMSs. And
although we may not ourselves have to explicitly worry about it, when
operating in a failover environment we are concerned with efficient
serialization of persistent objects from one cluster node to another,
and the backing stores for doing so may not be databases at all (in some
circumstances we do ourselves have to worry about writing this efficient
code).

The way I would look at this is that database vendors have spent a great
deal of time optimizing their products. ORM vendors have done the same -
Toplink/TLE/EclipseLink, for example, has a Java lineage dating back
over 10 years. I'd be the first one to admit that of all the software
shops out there that none have come close to creating a decent solution
for a specific problem, but Java ORM is not that problem, IMHO.

It seems to me like the problem conditions presented to you were
unreasonable. If you have no choice but to proceed along the joafip tack
then you have no choice but to proceed. But once you've got a robust
joafip implementation, take note of how many days you spent on it, then
record how many days it requires to implement a solution using, say,
EclipseLink (less than a week, I'll wager), and then compare
performance. I think you'll find that your employer wasted your time and
theirs.

AHS

 

[Pitch]

You mean 'super( someArg )', not 'super()'.

Nevermind, you're right.

I didn't know parent default contructor is automatically called in
child's constructor (if no other parent contructor is called).

So you cannot override parent's default contructor - which sucks.
Also, you cannot place any code before super(...) which I already new,
and it also sucks.

Anyone knows why is that so?

 

[RedGrittyBrick]

Nevermind, you're right.

I didn't know parent default contructor is automatically called in
child's constructor (if no other parent contructor is called).

So you cannot override parent's default contructor - which sucks.

You can't inherit it either.

Consider `class Foo extends JFrame'. This is a common idiom. The user of
this idiom does not need to know anything about the internals of JFrame,
only about it's published interface etc. The writer of Foo would not
normally be in a position to provide a replacement for JFrame's
constructor that would not cause problems with JFrames methods.

Supposing JFrames internals get rewritten in a later release of Java,
then the replacement constructor provided by Foo would very likely not
initialise the new internals at all - things would break.

Also, you cannot place any code before super(...) which I already new,
and it also sucks.

Consider the above, when writing my Foo constructor, I may want to use
JFrame methods such as add() - this add() method would be very unlikely
to work if I didn't already have a JFrame constructed.

 

[Eric Sosman]

Nevermind, you're right.

I didn't know parent default contructor is automatically called in
child's constructor (if no other parent contructor is called).

So you cannot override parent's default contructor - which sucks.

It would suck even more if you *could* override a
superclass' constructor. Think about it a second: You
write a nifty little class named Pitch, with a couple of
private elements the constructor initializes. I extend
Pitch with a subclass Catch which (somehow) overrides your
constructor. Since my overriding code cannot access the
private elements of your Pitch class (if it could, it would
make a mockery of `private'), how do those elements get
initialized?

Also, you cannot place any code before super(...) which I already new,
and it also sucks.

That is occasionally inconvenient, but not badly so.
Usually, what happens is that the subclass' constructor needs
to execute several statements (not just an expression) to
compute the argument(s) for the superclass' constructor, or
perhaps to validate them. You can't, for example, do

class Sub extends Super {
Sub(int value) {
while (! isPrime(value))
++value;
super(value);
}
}

.... to impose a restriction like "A Sub is a Super whose
`value' is known to be prime." You can, however, do

class Sub extends Super {
Sub(int value) {
super(nextPrime(value));
}
private static int nextPrime(value) {
while (! isPrime(value))
++value;
return value;
}
}

Anyone knows why is that so?

Since a Sub "is a" Super, and since a Super is responsible
for its own instantiation, every Sub *must* allow its Super --
and its GrandSuper and GreatGrandSuper, all the way back to
Object -- to do its own instantiation. If it were possible to
run arbitrary code on a Sub instance before its Super-ness had
been established and its Super invariants put in place, you'd
be working with a Sub that was a Super in name only, but not in
actuality.

 

[markspace]

I had to obey to my project manager and architect.
I understood they want to reduce stacking layer between the objets in
memory and the bytes in the file.

Huh, this bit is interesting. Why is main memory and disc memory
constrained?

Are you working in a restricted environment like JME?

Why is it better for your manager to pay you for several hours for work,
rather than to just go to the store and buy 2Gb of memory for $100?
(Which should be, what, worth one and a half hours of your time, minimum?)

 

[Lew]

I didn't know parent default contructor is automatically called in
child's constructor (if no other parent contructor is called).

It would have to be - you cannot construct an object unless all its superclass
aspects are constructed, in Java's case before subclass aspects.

So you cannot override parent's default contructor - which sucks.

Why does it suck?

You cannot override any constructor, not default, not explicit no-arg, not
with args.

Also, you cannot place any code before super(...) which I already new,
and it also sucks.

Again, why does that suck?

Anyone knows why is that so?

You do, if you give it two minutes' thought. You call a method or do whatever
in a constructor after the object has reached a certain level of construction.
In order to reach that level, the superclass aspects have to be constructed
first, even to reach the subclass's constructor aspect. If you want something
other than default superclass construction, you have to do it first.

Similar reasoning applies to where you put 'this(...)' invocations.

 

[Lew]

Why is it better for your manager to pay you for several hours for work,
rather than to just go to the store and buy 2Gb of memory for $100?
(Which should be, what, worth one and a half hours of your time, minimum?)

That's NTD (Taiwan), right?

 

[Tom Anderson]

That is one option.

java.math.BigDecimal may be good enough for many cases.

Or int/long and establishing a convention that you're working in pence, or
thousandths of a dollar, or whatever is suitable.

tom

 

[luc peuvrier]

Huh, this bit is interesting.  Why is main memory and disc memory
constrained?

Are you working in a restricted environment like JME?

Why is it better for your manager to pay you for several hours for work,
rather than to just go to the store and buy 2Gb of memory for $100?
(Which should be, what, worth one and a half hours of your time, minimum?)

We do not work on restricted environment, but ours customer do not
give to us so much memory on their server in wich application is
installed. In only one case we have enough memory; it is when we sale
the server with embedded application, it only run linux and our
application. But plenty of customers do not want a new PC in their
office.

An important point is we have to persist data to be able to stop and
restart the application, we do not do that so often.

We can also imagine use a 32Gbyte solid state ram-disk, there is some
we 15 days battery backup, or replication in flash memory.

Luc

 

[markspace]

We do not work on restricted environment, but ours customer do not
give to us so much memory on their server in wich application is
installed. In only one case we have enough memory; it is when we sale
the server with embedded application, it only run linux and our
application. But plenty of customers do not want a new PC in their
office.

We can also imagine use a 32Gbyte solid state ram-disk, there is some
we 15 days battery backup, or replication in flash memory.

OK, I would call that a restricted or embedded environment. Not quite
JME, but still pretty small footprint. You might want to mention that
in your documentation. Another ORM persistence layer is probably not
needed, but one that runs in a much smaller memory footprint might be
useful.

> An important point is we have to persist data to be able to stop and
> restart the application, we do not do that so often.

This also should be mentioned in your documentation. Performance does
not seem to be an issue, you might be slower than a regular ORM layer,
or unable to do efficient random access.

 

[Martin Gregorie]

luc peuvrier wrote:





OK, I would call that a restricted or embedded environment. Not quite
JME, but still pretty small footprint. You might want to mention that
in your documentation. Another ORM persistence layer is probably not
needed, but one that runs in a much smaller memory footprint might be
useful.




This also should be mentioned in your documentation. Performance does
not seem to be an issue, you might be slower than a regular ORM layer,
or unable to do efficient random access.

Start up speed can be important. Maybe Luc has start up time requirements
and starting from a database doesn't meet them.

The following story describes such a case:

I worked on a system that used a very large red-black binary tree for
fast lookups on a non-static key set. This was done for performance
reasons - we couldn't crack 300 lookups/sec doing the lookups on the
target RDBMS and hardware, but needed at least 7000/sec to handle
incoming data volumes. The red-black tree implementation ran at 25000/sec
with about 200M keys. First cut implementation loaded its tree from the
database BUT took 40 mins to start up. Too slow, so it was rewritten to
periodically dump the tree into a set of binary files and to restart from
the files after a tidy shutdown. Result: a sub-5 minute startup, but with
the ability to restart from the database after a crash.

This system was written in ANSI C. However the same start up requirements
could easily apply to a similar Java implementation.