Hm not so sure about the need to track field values. It makes things more
complicated. I'd have no problems with that if it brings new features, but
I can not see why
User u = new User();
u.setUserId("foo");
u.setPassword("secret");
u.load();
should be better than
Criteria criteria = new Criteria();
criteria.add(UserPeer.USER_ID, "foo");
criteria.add(UserPeer.PASSWORD, "secret");
criteria.setSingleRecord(true);
User u = (User) UserPeer.doSelect(criteria).get(0);
Of course, for the given example, your code would be a bit shorter, but
the criteria code is far more general. I do not believe in introducing
several equivalent ways to do the same thing.
I'd not object to tracking field values if there were other benefits, but
I can see none at the moment. One could have the idea of
improving save performance by saving only the modified fields, but the
dbcp does prepared statement caching which improves performance if you
always use the same prepared statement for saving, so its unclear whether
this would actually improve performance.
If you can see other benefits of field stat tracking, I'd be happy to hear
them.
Thomas
On Thu, 14 Dec 2006, Greg Monroe wrote:
How about this:
Assuming we add a mechanism to determine if a field
value has been set (e.g. via being loaded from the DB
or set by application code), have just a method like:
load();
The rules for load would work like this:
If the record has a primary key(s) defined and the
object has this set, the object will be loaded (or reloaded)
from the DB.
If there is no primary key or one is not set, it will
attempt to find a single record that matches all of the
"set" fields. If there is only one match, it load the
object. If there is more than one, it throws an exception.
This would be similar to the current Peer methods that
take an record object and build criteria from it.
The nice thing about this is that if you have tables
with other unique attributes, e.g. say a users table with
a numeric PK, but the userId is also unique. You can
do code like:
User u = new User();
u.setUserId("foo");
u.setPassword("secret");
u.load();
or
User u = new User();
u.setId(123);
u.load();
or
User u = new User();
u.setEmail("[EMAIL PROTECTED]");
u.load();
Depending on your needs. And if you have an existing
object and need to ensure the values match the database
one, just do:
rec.load();
FWIW, I started with the assumption about tracking field
level state because of the problems that can occure if
there are default values. IMHO, default values make the
current way to find things using the record object methods
very unreliable. The defaults get added into the Criteria
that is built and so you may not get what you expected
using these methods.
Thus the need for tracking "set" values vs defaults. Even
with true support for determining NULL values is not enough
because the field value you want to search for might be NULL.
E.g., if I have a table with 10 fields that have default
values and allow NULLS, and do something like:
RecordOm rec = new RecordOm();
rec.setField1(value1);
rec.setField2(value2);
rec.setField3(null);
List results = RecordOmPeer.doSelect(rec);
I should get records with field1=value1, field2=value2, and
field3=NULL and no more.
A way to do this would be to only allow the field storage
objects be accessed via "set" methods. Preferrably a single
set method for each fields (or a common setByName.... type
method). I.e. this.privateField= ... should be discouraged
internally in the generated objects. We should always use
the setField(..) methods unless absolutely needed.
This way, anytime a value is set, a field state flag could
be set as well. This would allow for a method like:
isModified( columnName );
Note that default values would be set by object constructors
and not set the field state. This way a record object can be
examined to determine what fields need to be used in creating
a matching Criteria.
-----Original Message-----
From: Thomas Fischer [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 10:10 AM
To: Apache Torque Developers List
Subject: Re: Torque 4.0 - Add delete() / loadByPk(...)
methods to Record object
+1 on both. Would it make sense to rename the loadByPk()
method reload() ?
If yes, it could make sense to generate the method also if no
pk exists but then throwing an exception.
I also like Thoams' idea of sessing isNew to triue after the
object has been deleted.
Do you mind adding this to the wiki page ?
http://wiki.apache.org/db-torque/NextRelease
Thomas
On Tue, 5 Dec 2006, Greg Monroe wrote:
I've often thought it would be nice for the generated
record object to
have a delete() and loadByPk() methods. It would help
simplify a lot
of code.
Of course the loadByPK method would only be added if there is a
primary key. And if there are multiple primary keys, the
method sig.
would be something like:
loadByPk( <colType> key1, <colType> key2...)
throw NoRowsException, TooManyRowsException
and the delete() method would throw an exception if called on a new
record.
Greg Monroe <[EMAIL PROTECTED]> (919)680-5050 C&IS
Solutions Team Lead
Duke Corporate Education, Inc.
333 Liggett St.
Durham, NC 27701
Duke CE Privacy Statement
Please be advised that this e-mail and any files
transmitted with it are confidential communication or may
otherwise be privileged or confidential and are intended
solely for the individual or entity to whom they are
addressed. If you are not the intended recipient you may not
rely on the contents of this email or any attachments, and we
ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email,
its contents, and all copies thereof immediately. Any
unauthorized dissemination, distribution or copying of this
communication is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
