i use the session id as a "random string" for linking to an invoice.
String uniqueId = storeInvoice.valueForKey("rowId") + "_" +
((Session)session()).sessionID();
storeInvoice.takeValueForKey( uniqueId , "uniqueId");
On Aug 7, 2007, at 12:47 AM, Jacob Mouka wrote:
There isn't a particular reason to storing it in a different table.
Usually something like a random string isn't related to any real
data, so it's just good practice so separate it. It really depends
on the context. For example, if the random string is kept in it's
own table it could be re-used to bookmark other objects. So I
agree, it's mostly a normalization thing.
On 7-Aug-07, at 12:37 AM, Ray Ackland wrote:
Thank you everyone for all for your comments. I'm probably going
to go for a random string. I contemplated SHA, but as I don't need
to actually encrypt any information, just link to it, I don't
believe it adds any functionality to me (as Jacob pointed out).
One question though Jacob: You mention storing the string in the
database along with a foreign key. I was going to be putting it in
a field in the same table (or more politically, in another
attribute of the same class) as the main data (the personal details).
I'm expecting your suggestion is just a normalisation thing, but
is there an advantage to what you suggest that I may be
overlooking? If I put it in a table of it's own, I guess that
means I can make the string the primary key and speed up its
lookup. Oui?
r
On 7/08/2007, at 15:48, Jacob Mouka wrote:
I second the use of SHA (or similar) to do this. It's very easy
to use as it's part of java, and quite secure.
http://java.sun.com/j2se/1.5.0/docs/api/java/security/
MessageDigest.html
Although, for your purposes it's good enough to generate a random
long string and store it in the db along with a foreign key to
your object. The SHA is more useful where the form values are
generated by the client and you need to verify their
authenticity, but your urls are completely in your control so
random strings are fine.
Jacob
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jameslist%
40primax.com
This email sent to [EMAIL PROTECTED]
{ primaxSTUDIO : http://primaxSTUDIO.com : 513.772.1223 }
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
