John McNally <[EMAIL PROTECTED]> writes:
> 1. Settle on using String as the PrimaryKey type.
> 2. Add a Key class that would be used as the type, I would like this to
> be backed by a String property.
> 3. Same as 2, but allow the property to handle Integer, ... as well as
> String.
>
> 1.
> Advantages
> a. simple
> b. more memory efficient than the extra object used in 2 and 3.
> Disadvantages
> c. less efficient than the Numeric types.
>
> I think the inefficiencies of the String compared to Integer for example
> are offset to a great degree in that we are often having to convert
> to/from a String representation of the id anyway.
>
> 2.
> Advantages
> a. OO design
> b. could help reduce the String parsing needed when a compound key is
> made from several columns.
> Disadvantages
> c. inefficient - especially when pulling object from storage using them
> for a couple simple operations and throwing them away.
>
> 3.
> Advantage
> a. Could potentially be more efficient than 2.
> Disadvantage
> b. Intake and Torque could potentially hide the complications, but I am
> having trouble figuring out how. :)
>
> As a final note, let me state that torque objects need to quit referring
> to foreign key columns using primitive types like "int".
Will option 1 work with multipart keys? If it works similarly to how it
currently does, I think that option 2 or 3 is better. The extra object
instantiation is a poor allocation of memory resources, but the idea of
parsing the key value every time to see if it is made of multiple parts is
extremely distasteful (even using String.indexOf(char)). There are tradeoffs
involved either way. Let's get some more comments on this. :)
I would also like to hear Rafal's thoughts on any LDAP integration that would
be involved with this.
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
