object relational database versus "inteligent" serialization
in [Java Programming]
|
From: luc peuvrier on 8 Feb 2010 23:40 On Feb 9, 2:19 am, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 08-02-2010 14:55, luc peuvrier wrote: > > > On 8 f v, 11:31, Arved Sandstrom<dces...(a)hotmail.com> wrote: > >> 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. > > 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
From: Arved Sandstrom on 9 Feb 2010 04:00 luc peuvrier wrote: > On 8 f�v, 11:31, Arved Sandstrom <dces...(a)hotmail.com> wrote: [ SNIP ] >> 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 > >> AHS 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
From: Pitch on 9 Feb 2010 04:49 In article <hkpilb$48g$1(a)news.albasani.net>, noone(a)lewscanon.com says... > Pitch wrote: > > What if the new parent-class has a non-empty constructor that needs to > > be called with super()? > > 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? -- stirr your cofee properly
From: RedGrittyBrick on 9 Feb 2010 06:00 On 09/02/2010 09:49, Pitch wrote: > In article<hkpilb$48g$1(a)news.albasani.net>, noone(a)lewscanon.com says... >> Pitch wrote: >>> What if the new parent-class has a non-empty constructor that needs to >>> be called with super()? >> >> 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. 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.
From: Eric Sosman on 9 Feb 2010 08:01
On 2/9/2010 4:49 AM, Pitch wrote: > In article<hkpilb$48g$1(a)news.albasani.net>, noone(a)lewscanon.com says... >> Pitch wrote: >>> What if the new parent-class has a non-empty constructor that needs to >>> be called with super()? >> >> 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. 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. -- Eric Sosman esosman(a)ieee-dot-org.invalid |