Patrick,
I meant "tuned" as in not including columns in the SQL update "set"
clause if they weren't really changed by the app (even if a setter
was called, the old and new values may be the same).
The update "set" clause is 100% portable SQL.
So I'm not entirely clear what you mean by:
"tuned" for your implementation
> -----Original Message-----
> From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 4 April 2007 5:44 p.m.
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Forced getter/setter access
>
> > If you are going to issue "tuned" updates to the DB,
> determining what
> > "really" changed (as opposed to what setter methods were
> > called) can avoid unnecessary DB overheads.
>
> ... "tuned" for your implementation, that is. Often, business
> needs require that a transaction involves a large number of
> objects, and it would be unfortunate to have to compromise on
> transaction integrity just for the sake of a particular
> implementation. It's not just a matter of needing to
> periodically call flush() during a tx, but rather of having
> to design transactions that don't read too many objects.
>
> Happily, with OpenJPA, this is a non-issue, regardless of
> property or field access.
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________
> _________
> Notice: This email message, together with any attachments,
> may contain information of BEA Systems, Inc., its
> subsidiaries and affiliated entities, that may be
> confidential, proprietary, copyrighted and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
> > -----Original Message-----
> > From: Evan Ireland [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 03, 2007 10:39 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: RE: Forced getter/setter access
> >
> > Granted, but with a reasonable implementation the cost
> should be low
> > for:
> >
> > "at commit / flush time compare the current values with the
> original
> > values to figure out what to write back to the database."
> >
> > If you are going to issue "tuned" updates to the DB,
> determining what
> > "really" changed (as opposed to what setter methods were
> > called) can avoid unnecessary DB overheads.
> >
> > Anyway at the end of the day, you must use the
> getters/setters because
> > the spec says so, and you should write portable apps where possible
> > :-)
> >
> > > -----Original Message-----
> > > From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, 4 April 2007 5:21 p.m.
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: RE: Forced getter/setter access
> > >
> > > The main reason to support getter / setter access is for
> > > implementations that cannot intercept field accesses. So, the
> > > getters and setters are there so that the JPA implementation can
> > > create a subclass of your entity type (hence the no-final-classes
> > > rule) and track what happens as you invoke the setters
> and getters.
> > > In other words, your business methods become part of the JPA
> > > implementation's domain.
> > >
> > > So, when using property access, your contract with the
> JPA provider
> > > is that you'll access persistent attributes only through
> the setters
> > > and getters, which allows the implementation to track what you do
> > > and when you do it. If you could directly access the underlying
> > > state, the implementation would have no way to know what happened
> > > during the course of a transaction. This, in turn, would
> mean that
> > > the implementation would have to keep a copy of every bit of data
> > > that you read during a transaction, and then at commit /
> flush time
> > > compare the current values with the original values to figure out
> > > what to write back to the database.
> > >
> > > As it turns out, when you use OpenJPA, all your direct field
> > > accesses are replaced with synthetic static methods
> anyways, so from
> > > a performance standpoint, you'll see equivalent behavior
> either way.
> > > In my experience, persistent domain model field access
> performance
> > > in tight loops is rarely actually a performance bottleneck; it's
> > > almost always going back and forth to the database that ends up
> > > being the bottleneck, and thus the most important place
> to optimize.
> > >
> > > -Patrick
> > >
> > > --
> > > Patrick Linskey
> > > BEA Systems, Inc.
> > >
> > > ______________________________________________________________
> > > _________
> > > Notice: This email message, together with any attachments, may
> > > contain information of BEA Systems, Inc., its
> subsidiaries and
> > > affiliated entities, that may be confidential, proprietary,
> > > copyrighted and/or legally privileged, and is intended
> solely for
> > > the use of the individual or entity named in this message. If you
> > > are not the intended recipient, and have received this message in
> > > error, please immediately return this by email and then delete it.
> > >
> > > > -----Original Message-----
> > > > From: Phill Moran [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, April 03, 2007 10:02 PM
> > > > To: open-jpa-dev@incubator.apache.org
> > > > Subject: Forced getter/setter access
> > > >
> > > > Can anyone explain why this rule is in effect:
> > > >
> > > > When using property access, only the getter and setter
> > method for a
> > > > property should ever access the underlying persistent field
> > > directly.
> > > > Other methods,
> > > > including internal business methods in the persistent
> > > class, should go
> > > > through the getter and setter methods when manipulating
> > persistent
> > > > state. (section 2.1.4 OpenJPA manual)
> > > >
> > > > This seems rather execution costly. If ,for instance, I
> > have a Size
> > > > class with hieght, width and length then to calculate
> and return
> > > > volume I suffer a three method call overhead:
> > > > return getWidth() * getLength() * getHieght();
> > > >
> > > > This is opposed to a more efficient
> > > >
> > > > Return height * width * length
> > > >
> > > > Phill
> > > >
> > > >
> > >
> > > Notice: This email message, together with any attachments, may
> > > contain information of BEA Systems, Inc., its
> subsidiaries and
> > > affiliated entities, that may be confidential, proprietary,
> > > copyrighted and/or legally privileged, and is intended
> solely for
> > > the use of the individual or entity named in this message. If you
> > > are not the intended recipient, and have received this message in
> > > error, please immediately return this by email and then delete it.
> > >
> >
> >
>
> Notice: This email message, together with any attachments,
> may contain information of BEA Systems, Inc., its
> subsidiaries and affiliated entities, that may be
> confidential, proprietary, copyrighted and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
