so, basically, you are suggesting that I store them flat lowercase and put a 
constraint on these two strings and just lose any case the user entered which 
is fine I think.

With the lowercase assured the constraint will prevent duplicates and I’d catch 
that exception during creation and handle it

> On Nov 24, 2021, at 12:19 AM, Samuel Pelletier <sam...@samkar.com> wrote:
> 
> If your usernames (or keyString) are case insensitive, store them in a 
> normalized case (in lowercase for exemple). 
> 
> You can add an overridden 
> public void setKeyString(String value) {
>       if (value != null) {
>               value = value.toLowerCase();
>       }
>       super.setKeyString(value);
> }
> 
> You may also specify a collation to the column in the database if you want to 
> preserve case but index and compare as case insensitive.
> 
> Samuel
> 
>> Le 23 nov. 2021 à 17:26, Jesse Tayler via Webobjects-dev 
>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> a 
>> écrit :
>> 
>> 
>> 
>>> On Nov 23, 2021, at 5:17 PM, Paul Hoadley <pa...@logicsquad.net 
>>> <mailto:pa...@logicsquad.net>> wrote:
>>> 
>>> Are you able to paste in some code? There's probably a solution, but this 
>>> is getting a bit hard to follow in the abstract.
>>> 
>> 
>> So, I fetch first
>> 
>>              EOQualifier qual = 
>> DataPoint.TYPE.eq("twitter").and(DataPoint.KEY_STRING.likeInsensitive(username));
>> 
>> If there’s no EO, I create and save right away but at high volumes this 
>> CREATE statement must create only unique entries and those entries must 
>> match this qualifier which uses insensitive case
>> 
>> I figure the pattern should be to create an object with a DB level 
>> constraint such that a duplicate raises an error, upon catching that error, 
>> I can simply fetch again and return the one, single EO representing that 
>> record
>> 
>> When I tried regular constraints I did not see a way to replicate the 
>> required logic, so I found some advise about triggers and some other things 
>> I didn’t fully understand.
>> 
>> I realize usernames generally have this kind of issue, so I figure this is a 
>> design pattern that is hardly unique to us and I should get advice!
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com 
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com 
>> <https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com>
>> 
>> This email sent to sam...@samkar.com
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to