the spec says:
"When instances are queried,
navigated to, or modified, instantiation of instances
and their fields and garbage collection
of unreferenced instances occurs without any explicit
control"
So that means that whatever implementation is used to
map between identity and Object, it can't
I haven't profiled L2 caching done by database, if someone has I'd
really be interested in results.
Anyway, I wouldn't use WeakReference for caching, SoftReference seems to
be better alternative.
-Matej
Geoff hendrey wrote:
> No doubt L2 caching can speed up apps. Most databases
> implement ca
No doubt L2 caching can speed up apps. Most databases
implement caching already. With L2 cache comes another
set of problems, and when you get deep enough into
them, you may wish you had not used the L2 cache, but
simply relied on effective caching in the database. On
the other hand, many L2 cachi
Yes, it looks like SimpleOrm has similar objectives.
You can't help but come to some of these same
conclusions. Some of the solutions are amlost
self-evident after working with, shall we say,
"complex-orm" for long enough.
Nope, I've not read that book, but I'll put it on my
list. :-)
-geoff
---
I was more concerned about second level cache. When using loadable
detachable models it is possible to hold only object id in session,
loading the entire object on the beginning on request. In this scenario
second level cache really helps. I think this is feature that lot of
people would be mis
Most ORMS have 2 kinds of L1 caching:
1) caching of compiled queries
2) caching of POJOs, where the cache is keyed by
identity
Shades does (1).
Shades does not do (2).
I found that the L1 cache was actually redundant. Why?
Because most modern frameworks, like Wicket, take the
pojo, and hold o
aBook and anAuthor are RecordCandidate instances.
RecordCandidates are not pojo's, just structures used
to represent the data behind a pojo, for the purpose
of forming a query.
aBook.getAuthor() would not compile because
RecordCandidate has no getAuthor method.
-geoff
--- Martijn Dashorst <[E
And how is caching done if you can't query objects by identity? Or does
this question make even sense?
-Matej
Geoff hendrey wrote:
> Ohh my god yes
>
> I ran into all these problems in JDOMax, and they are
> all solved in Shades.
>
> I won't drop the name, but some very influential
> perso
Ohh my god yes
I ran into all these problems in JDOMax, and they are
all solved in Shades.
I won't drop the name, but some very influential
person on EJB and JDO specs now believe that exposing
object identity in the form of API's was a mistake.
I agree -- you will notice shades has no metho
I understand your position... Shades is your hobby, pet project and it
would be nice that people find it helpful. I think there is a market
for it, as other people have come to the same conclusion.
At my company at least I and a collegue of mine are very interested in
trying out http://www.simpleo
I also read your blog, and it sounds very interesting.
Just a quick question (probably should've done so on the blog though):
Does it hold that after getting a book and author from the results that:
aBook.getAuthor() == anAuthor
and/or
aBook.getAuthor().equals(anAuthor)
?
Martijn
On 8/2
Yeah, forgot about that. http://code.google.com/hosting/
Eelco
On 8/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> there is also google oss hosting which i have heard good things about.
> http://code.google.com i believe.
>
> -Igor
>
>
>
> On 8/26/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote
another interesting problem i find with identity in full blown orms is that it can cause a nasty cascade of loading object graph when using "business" identity instead of db identity.if you have school->semester->class relationships and you do not want to depend on db identity which is the "recomme
there is also google oss hosting which i have heard good things about. http://code.google.com i believe.-IgorOn 8/26/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
We left Codehaus because we had to wait for weeks for even an answerto Jonathan's request of adding another committer (me). So we deci
We left Codehaus because we had to wait for weeks for even an answer
to Jonathan's request of adding another committer (me). So we decided
to go to SF where we were less dependent on other people.
SF works. I've heard good stories about http://developer.berlios.de/.
And you could consider proposin
We left codehaus because at that time we had some issues with the
support. They didn't respond in time and somtimes not at all. But
Martjin may give you more details
Juergen
On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
> Hi Igor,
>
> Cool.
>
> I'm trying to find the right venue for open s
Hi Igor,
Cool.
I'm trying to find the right venue for open sourcing
Shades, and for putting up the javadocs, etc. I was
wondering why you guys left codehaus?
-geoff
--- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ive read your blog, and agree with some points you
> make about full orm
> solutio
ive read your blog, and agree with some points you make about full orm solutions. but as i said i couldnt grasp everything from looking at the code youve provided. are you planning on writing tutorials for shades in the near future as it sounds appealing.
-IgorOn 8/26/06, Geoff hendrey <[EMAIL PROT
Sure - but honestly I don't want to convince anyone
they need Shades.
One problem I found with JDO was that the
PersistenceManager was not serializable. Another is
that detachment had to be handled explicitely.
In Shades all pojo's are inherently detached. Change
tracking is automagic. The Datab
:-( That's just what lots of people say in java forums when a new
Wicket release is announced :
"We already have [replace with the framework you think is the market
leader] , why the hell should we learn a new one ?"
One of java's strength is in the choice we have to make our job done :-)
i glanced over the code - but i dont get it after the first glance. perhaps you can explain what difficulties you hit when using wicket and an orm to help us better understand.seems to me like you are trying to work with a ui connected to a persistence layer - without a service layer in between. ha
because there is always an opportunity to make the wheel rounder - aka innovation :)-IgorOn 8/26/06, Korbinian Bachl <
[EMAIL PROTECTED]> wrote:hi,my thought is: with EJB3 and hibernate (and both together if you want) - why
do we need more ?regards,korbinian> -Ursprüngliche Nachricht-> Von:
hi,
my thought is: with EJB3 and hibernate (and both together if you want) - why
do we need more ?
regards,
korbinian
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Geoff hendrey
> Gesendet: Samstag, 26. August 2006 18:54
> An: Wicke
23 matches
Mail list logo
