Your database might allow you to create function based indexes in which case
you can just put a unique index on lower(username). If that can't be done,
then yes you pretty much need to add a derived field lusername or whatever
you want to call it, and ensure your bean populates it properly.
Is your comparison of username/password case insensitive? Perhaps you can
force the field to lower case earlier in the process (for example the
setUsername() method could do the work) if you don't really need to keep the
case information.
Cheers
Jay Walters
-----Original Message-----
From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 8:58 PM
To: [EMAIL PROTECTED]
Subject: Modeling users with entities
Hi everyone, I am dumbfounded by what I imagine should be a common and
many-times-solved problem. I would love to know how people are
addressing this situation:
I have a more-or-less typical membership-based website. Users can sign
up and create accounts; users can choose their unique login name.
I've modeled the user as a CMP entity bean called Member. Now, what to
choose as the primary key?
The natural option (and the one I chose) was to use the login name as
the primary key. But I want to make this key case-insensitive (there
cannot be both "Bob" and "bob"), and there doesn't seem to be a natural
way of doing this.
I have a feeling it will work if a) my PK class does case-insensitive
comparisons and b) I instruct the my container to use more interesting
sql for findByPrimaryKey(). But I'm not sure that (b) is something I
will be able to do for all containers. Actually, I'm not even sure that
this is something I'll be able to do for my own container. Is this the
"correct" solution to the problem, and I should stop worrying about it?
Another approach which has some significant appeal is to use a generated
integer primary key independent from the name. Now the problem is, how
do I guarantee that two users do not create accounts nearly
simultaneously with the same login name? It seems to me that simply
ensuring that findByName() returns nothing and then saving the value
opens up the opportunity for a race condition. How can I protect
against this?
Ok, I could add another entity/table, "AllocatedName" which simply
stores the downcased version. Or I could use a singleton RMI server to
provide a locking service. But isn't this a little excessive? There
has got to be an easier way... and given the number of sites out there
that work like mine, this must have been done dozens of times already.
What am I missing?
Thanks,
Jeff Schnitzer
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
