Fedor Karpelevitch wrote:
>
> 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.
BaseObject defines getId/setId where the id is supposed to be a unique
identifier for an object, it does not have to be related to something in
a database. The torque objects are overriding these methods.
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.
>
The thought of implementing using inner classes crossed my mind. I have
not completely mastered the use of inner classes. I have used them, but
am always a little unclear on scope issues and how the various modifiers
work, etc. So I started with something that should accomplish what I am
after (a string identifier that can be used to indicate the object in a
query parameter.) I like how an inner class could help to identify the
PK attributes as a group. But it needs to provide individual access to
the attributes similar to how they are now and it should present a
string representation similar to what I have defined for easy use in a
html form.
> also the association code in templates whould be much nicer in the
> AppData which I will probably implement shortly.
I'm sure it can be written easier in Java and the results presented for
use in the templates, especially since I am looping over the entire
schema a couple times. I think you caught me putting too much logic in
my templates, even though they are "engineer-only" templates. :)
Try to make sure the resulting classes would not change, as I think I
covered some cases such as when a table contains multiple foreign keys
to the same table.column, in an intuitive way. Of course your free to
correct for any cases I did not anticipate. :)
>
> Tell me what you think. Thanks.
>
> Fedor.
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
