Hi!
My few cents.
what about getPrimaryKey/setPrimaryKey instead of getId/setId. These
seem to be more apropriate names to me since for an x-ref table having
composite PK which consists of few "real" IDs and referring to such PK
as Id would be rather confusing. I've also looked at your implementation
of these Ids and would like to suggest an alterantive:
instead of string concatenation define a PrimaryKey class for each
Object. I would make it an inner class i.e.
ScarabIssueAttributeValue.PrimaryKey and instance var of this type
(primaryKey) with get/set methods returning Objects' field values.
This seems to be a bit cleaner than string mangling (at least it seems
so to me). And "associate" methods should rather use PrimaryKey objects
since only PK or a UK can be referenced by a FK.
also the association code in templates whould be much nicer in the
AppData which I will probably implement shortly.
Tell me what you think. Thanks.
Fedor.
John McNally wrote:
> Sean Legassick wrote:
>
>> On 2000.11.29 22:33:34 +0000 John McNally wrote:
>>
>>> My solution
>>> after a couple minutes thought is to extend or build around a TreeMap
>>> with keys being the pk column names and values being the pk values. The
>>> toString() could give something like 121:2:45888 as the id where the
>>> separator can be set. So that the id representation does not have to
>>> contain the key names I will add a String vector to the Peers that
>>> defines the order.
>>
>> That sounds like a pretty good solution for a couple of minutes thought :-)
>>
>> And that would certainly address my concern...
>>
>> +1
>>
>
>
> Not a good enough solution, though, I am afraid. I am thinking the base
> objects produced by torque should just implement their own getId and
> setId methods. A simple example with a single column id.
>
> public class Foo extends BaseObject
> {
> int foo_id;
> String name;
>
> public void setFooId(int v) {foo_id=v;}
> public void setName(Strng v) {name=v;}
>
> public int getFooId() {return foo_id;}
> public String getName() {return name;}
>
> // my proposal
> public void setId(Object id)
> {
> // maybe add try block
> foo_id = Integer.parseInt(id.toString());
> }
>
> public Object getId() { return new Integer(foo_id);}
> }
>
> The getId/setId problem can be solved easily here through torque, by
> setting the JavaName attribute to "Id". (Though this is only true due to
> getId being defined in BaseObject as returning an int, something I would
> like to change.)
>
> But I think the new approach is more flexible. For example if the class
> corresponds to a table with two pk columns:
>
> public class FooBar extends BaseObject
> {
> int foo_id;
> int bar_id;
> String name;
>
> public void setFooId(int v) {foo_id=v;}
> public void setBarId(int v) {bar_id=v;}
> public void setName(Strng v) {name=v;}
>
> public int getFooId() {return foo_id;}
> public int getBarId() {return bar_id;}
> public String getName() {return name;}
>
> // my proposal
> public void setId(Object id)
> {
> StringTokenizer st = new ST(id.toString(), ":");
> foo_id = Integer.parseInt(st.nextToken());
> bar_id = Integer.parseInt(st.nextToken());
> }
>
> public Object getId()
> {
> return foo_id + ":" + bar_id;
> }
> }
>
> My earlier idea made it more difficult to manipulate the simple
> attributes that make up the OID. The object itself, other business
> objects, and the peer(s) can make use of the simple attributes, while
> the ui/application layer (modules) would primarily be concerned with the
> possibly composite getId/setId methods.
>
> The one major change this entails is resetting the return type of the
> getId() method in BaseObject to Object. I wanted to do this some time
> ago, when I was upgrading IDBroker and BasePeer, but was hesitant to
> make the change and instead added a getIdAsObject() method. I really
> want the main getId method to get away from the association with the
> int. There is a getIdAsInt() method that can be substituted where a
> current app is assuming getId() returns an int.
>
> Thoughts and any concerns reqarding the change to BaseObject?
>
> John McNally
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
