Re: Single thread creation queue?
Re: Single thread creation queue?
- Subject: Re: Single thread creation queue?
- From: Jesse Tayler via Webobjects-dev <email@hidden>
- Date: Wed, 24 Nov 2021 08:02:18 -0500
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 <email@hidden> 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
>> <email@hidden <mailto:email@hidden>> a
>> écrit :
>>
>>
>>
>>> On Nov 23, 2021, at 5:17 PM, Paul Hoadley <email@hidden
>>> <mailto:email@hidden>> 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 (email@hidden
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden