[Opensim-users] Uniqueness in MySQL 'useraccounts'

[Karen Palen]

I suspect the answer is that you need more information than just those
two fields.

I am thinking of the fairly common case in Hypergrid usage where two
avatars have the same name, distinguished only by the field that tells
their host system.

I have used this for testing on many occasions.

Karen

On 03/05/2012 04:45 AM, Kevin Buckley wrote:
> Hi - Thanks for the quick response.
>
> I understand the reasons why PrincipalID is the Primary Key and hence should
> be unique (and I now realise my original question was malformed).
>
> The actual question is: Why isn't 'Name' (the composite key including
> FirstName and LastName) defined as Unique?
>
> Defining it as Unique certainly works and causes MySQL to throw Error 1062
> in response to an attempt to create  a duplicate FirstName/LastName entry
> which is the (my) required behaviour.
>
> So I am wondering why 'Name' isn't defined as Unique when the database
> tables are created (or upgraded) by Opensim, given that it goes to the
> trouble of defining it in the first place!
>
> Thanks.
>
> -----Original Message-----
> From: opensim-users-bounces at lists.berlios.de
> [mailto:opensim-users-bounces at lists.berlios.de] On Behalf Of M.E. Verhagen
> Sent: 04 March 2012 23:42
> To: opensim-users at lists.berlios.de
> Subject: Re: [Opensim-users] Uniqueness in MySQL 'useraccounts'
>
> the PrincipalID field is already the primary key.
>
> There can be only one primary key.
>
> This uuid key is the unique identifier on wich an avatar is idenified.
>
> When you write you own member system with direct database manipulation
> than you should check if the avatar is unique or else you will end up
> with more than one avatar name attached to an uuid.
>
>
>
> 2012/3/4, Kevin Buckley <kevin at buckley70.freeserve.co.uk>:
>> I hope this is not covering old ground.  I'm playing with a member system
>> for standalone OpenSim and I'm trying to decide the best way to deal with
>> the FirstName/LastName uniqueness issue (as my sign-up process allows
>> multiple, concurrent users).
>>
>>
>>
>> I notice that the default useraccounts table has a composite key called
> Name
>> (which consists of FirstName and LastName).  But it isn't defined as a
>> primary key.  So duplicate name inserts are not trapped as a result of
> that
>> (I believe that is the reason, anyway).
>>
>>
>>
>> Does anyone know if there is a reason 'Name' is not defined as a primary
>> key?  Is there a problem with making it so?
>>
>>
>>
>> I have other ways I can deal with this but trapping it at the useraccounts
>> table insert would be the best way.
>>
>>
>>
>> Thanks.
>>
>>
>