RE: Torque 4.0 - Add delete() / loadByPk(...) methods to Record object

One reason to track field state this is to make sure 
the current Peer.doSelect/Delete/Insert( Record ) methods
will work as expected.  As I said, currently default and
null values get add into these if you don't set the
primary key. E.g., with the current code base, the code:

User u = new User();
u.setUserId("foo");
List results = UserPeer.doSelect(u);

will ONLY return records where userId=foo and ALL 
other non-primary fields are equal to the defaults or 
null values. IHMO, the expected behaviour would be
to return all records with userId = foo.

Tracking what has been set would allow this broken 
behaviour to be corrected.

Or do we just drop the do*( Record ) methods totally?


> -----Original Message-----
> From: Thomas Fischer [mailto:tfischer@xxxxxxxxxx] 
> Sent: Thursday, December 14, 2006 2:52 PM
> To: Apache Torque Developers List
> Subject: RE: Torque 4.0 - Add delete() / loadByPk(...) 
> methods to Record object
> 
> 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@xxxxxxx");
> > 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@xxxxxxxxxx]
> >> 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@xxxxxxxxxx> (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@xxxxxxxxxxxxx
> >> For additional commands, e-mail: torque-dev-help@xxxxxxxxxxxxx
> >>
> >>
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-dev-unsubscribe@xxxxxxxxxxxxx
> > For additional commands, e-mail: torque-dev-help@xxxxxxxxxxxxx
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@xxxxxxxxxxxxx
> For additional commands, e-mail: torque-dev-help@xxxxxxxxxxxxx
> 
>