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