db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject RE: Torque 4.0 - Add delete() / loadByPk(...) methods to Record object
Date Thu, 14 Dec 2006 19:52:10 GMT
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("foo@bar.org");
> 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:tfischer@apache.org]
>> 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 <Monroe@DukeCE.com> (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: torque-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: torque-dev-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message