Hi Jesse,
We often have a someValue_unique attribute that is set when the main editable
version of it is set. It isn’t editable by the user directly, but is adjusted
when the other value is update — and it is used for uniquing, i.e.:
public void setSomeValue(String value){ super.setSomeValue(value);
_cleanupSomeValue_unique(); }
-G
> On Nov 24, 2021, at 5:02 AM, Jesse Tayler via Webobjects-dev
> <[email protected]> wrote:
>
> 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 protected]
>> <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> a
>>> écrit :
>>>
>>>
>>>
>>>> On Nov 23, 2021, at 5:17 PM, Paul Hoadley <[email protected]
>>>> <mailto:[email protected]>> 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 protected]
>>> <mailto:[email protected]>)
>>> 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 [email protected] <mailto:[email protected]>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/g%40knuckleheads.net
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
