|
RE: Torque 4.0 - Add delete() / loadByPk(...) methods to Record object: msg#00059jakarta.turbine.torque.devel
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 > > |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | RE: Should database.dtd alway be the current version?: 00059, Greg Monroe |
|---|---|
| Next by Date: | RE: Should database.dtd alway be the current version?: 00059, Thomas Fischer |
| Previous by Thread: | Re: Torque 4.0 - Add delete() / loadByPk(...) methods to Record objecti: 00059, Thomas Fischer |
| Next by Thread: | RE: Torque 4.0 - Add delete() / loadByPk(...) methods to Record object: 00059, Thomas Fischer |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |