Hi Andrew,
can I do this programmatically (without using SQL's)?
Sheldon
--
View this message in context:
http://cayenne.195.n3.nabble.com/lazy-loading-tp3863908p3899950.html
Sent from the Cayenne - User mailing list archive at Nabble.com.
>>> You have to inflate your cache anew from DB in every transaction.
>>> You don't have any data when you start.
>>
>> Sure, that's unavoidable if you want to do optimistic locking.
>
> You can do optimistic locking with cached data just as well. It
> doesn't have to come from the same transactio
Hi Sheldon;
You can just create an EJBQLQuery that extracts those specific columns
(expressed as entity attributes' names) and then run the query and
you'll pull back that data. A crude example of such a query;
"SELECT o." + Foo.CODE_PROPERTY+" FROM "+Foo.class.getSimpleName()+" o
WHERE o."
What I mean is,
if I have a Table with n columns (col1, col2, col3 ...) and want load only
the value of col1 and col3 (without loading col2 and the others).
Is this example possible?
Sheldon
--
View this message in context:
http://cayenne.195.n3.nabble.com/lazy-loading-tp3863908p3877037.html
Hi Michael,
I just looked up the def of Optimistic Locking and it forwarded me to
Optimistic Concurrency Control (so I am not sure of the distinction just yet).
But I *think* that the behavior that I have seen in my webapp would be your
implementation of optimistic locking.
RE: "As for faulti
Hi Joe,
It mainly sounds like you care about optimistic locking. Cayenne can
use whichever columns you select to test for external changes upon an
UPDATE. As for faulting data into memory, Cayenne will get the
freshest data the DB has at that point, excluding any pending
transactional changes.
OK, I am getting confused as to the subject that we are arguing. My interest
is specifically with the thesis and conclusion:
>>> Cayenne doesn't care about staleness. ... If data isn't available yet, just
>>> load it - and accept the risk that the application may now be working with
>>> partly
Let me try to think how to better present my point. I'll try to get back in a
few days.
On Mar 30, 2012, at 5:34 PM, Joe Baldwin wrote:
> Andrus,
>
> I am pretty smart, but I have NO idea what you just said, :) I would really
> like to understand your argument as it sounds like something tha
On Mar 30, 2012, at 5:37 PM, Durchholz, Joachim wrote:
>> You have to inflate your cache anew from DB in every transaction.
>> You don't have any data when you start.
>
> Sure, that's unavoidable if you want to do optimistic locking.
You can do optimistic locking with cached data just as well.
On Mar 30, 2012, at 5:01 PM, Durchholz, Joachim wrote:
>>> Thanks for explaining. If this is so, it sounds... unscalable.
>>
>> How so?
>
> You have to inflate your cache anew from DB in every transaction.
> You don't have any data when you start.
Sure, that's unavoidable if you want to do opti
Andrus,
I am pretty smart, but I have NO idea what you just said, :) I would really
like to understand your argument as it sounds like something that might be
important to my project. Do you have an analysis somewhere I read up on this?
Thanks
Joe
On Mar 30, 2012, at 10:12 AM, Andrus Adamc
On Mar 30, 2012, at 5:01 PM, Durchholz, Joachim wrote:
>> Thanks for explaining. If this is so, it sounds... unscalable.
>
> How so?
You have to inflate your cache anew from DB in every transaction. You don't
have any data when you start.
However I don't think you are right in your assessmen
> Thanks for explaining. If this is so, it this sounds... unscalable.
How so? At worst, the memory footprint doubles (plus maybe a logN factor), that
sounds pretty scalable to me. ("non-scalable" is "more than NlogN overhead" in
my book; I do not know of any substantially better way to implement
>> Cayenne doesn't care about staleness. It's the application's
>> task to ensure that Pojo networks are updated to the current
>> DB state at the beginning of an application-side transaction.
>> If data isn't available yet, just load it - and accept the
>> risk that the application may now be work
Thanks for explaining. If this is so, it this sounds... unscalable.
On Mar 30, 2012, at 4:45 PM, Durchholz, Joachim wrote:
>>> Hibernate strictly controls the staleness of objects. If a Session
>>> closes, the objects become detached and potentially stale, and
>>> there's no way to make the cur
>> Hibernate strictly controls the staleness of objects. If a Session
>> closes, the objects become detached and potentially stale, and
>> there's no way to make the current again (except by transferring
>> their contents to objects of a new Session). Hibernate goes to
>> great lengths to protect t
About this comment:
On Mar 30, 2012, at 8:56 AM, Durchholz, Joachim wrote:
> Cayenne doesn't care about staleness. It's the application's task to ensure
> that Pojo networks are updated to the current DB state at the beginning of an
> application-side transaction. If data isn't available yet, j
> Hibernate strictly controls the staleness of objects. If a Session closes,
> the objects become detached and potentially stale, and there's no way to make
> the current again (except by transferring their contents to objects of a new
> Session). Hibernate goes to great lengths to protect that
I agree the difference is the approach.
Hibernate strictly controls the staleness of objects. If a Session closes, the
objects become detached and potentially stale, and there's no way to make the
current again (except by transferring their contents to objects of a new
Session). Hibernate goes
Remember the "buy a Mac" commercials? When (in the commercial) the Keynote
Speaker's presentation was critically interrupted by a Windoz crash, and
failure to continue and causing a delay in the presentation, people in the
audience were suggesting all sorts of trial solutions one after another
Just re-read my post, and wanted to clear up ambiguous grammar (i.e. poor word
use-ments :) )
> lack of the cogent behavior mechanisms present in Cayenne
This should have said: "lack of cogent behavior mechanisms (that are already
present in Cayenne)"
I totally have to learn English (my nati
Just jumping in here but this may also be interesting to consider given the
discussion so far:
> Why can't Hibernate just load objects on demand?
> Every month someone has the idea that Hibernate could instead of throwing a
> LazyInitializationException just open up a new connection to the data
John,
there was an excellent thread about this in 2010 (which I sequestered for the
very reason you point out). I am going to attach one of Michael Gentry's
comments. But I also wanted to say, based on my understanding, in this case
the "jokes" are not superfluous, but are at the heart of the
23 matches
Mail list logo
