Just getting around to adding this, but can’t figure out how to do this as part
of my migration code:
Currently I have:
userTable.addUniqueIndex("uniqueUser",
userTable.existingColumnNamed("c_name"));
Is there something along the lines of:
userTable.addCaseInsensitiveUniqueIndex("uniqueUser",
userTable.existingColumnNamed("c_name"));
Or is there some way of adding such a constraint using EOModeler?
thanks,
Jeff
> On Mar 27, 2017, at 3:52 AM, Musall, Maik <m...@selbstdenker.ag
> <mailto:m...@selbstdenker.ag>> wrote:
>
> Hi,
>
> I would just create a unique function based index, like this:
>
> CREATE UNIQUE INDEX indexname ON MyTable( UPPER(columnName) );
>
> No extensions required. Works with every RDBMS that supports function based
> indexes.
>
> Maik
>
>> Am 27.03.2017 um 02:29 schrieb Paul Hoadley <pa...@logicsquad.net
>> <mailto:pa...@logicsquad.net>>:
>>
>> Hi Jeff,
>>
>> On 25 Mar 2017, at 04:16, Jeff Schmitz <jeffschm...@icloud.com
>> <mailto:jeffschm...@icloud.com>> wrote:
>>
>>> Just a quick question on how to create a case insensitive unique index in
>>> an ERXMigration?
>>
>> As Samuel mentioned, this is going to be database-dependent. We’ve been
>> using PostgreSQL’s CITEXT type for a year or so now, and it works as
>> designed. Because it’s an extension type, you need to run:
>>
>> CREATE EXTENSION IF NOT EXISTS citext;
>>
>> at some point—we do this in a migration upgrade(). You can then add and
>> alter columns and add indexes in the usual way. There’s a brief discussion
>> on performance here:
>>
>> http://stackoverflow.com/questions/31133603/in-postgresql-weird-issue-about-citext-performance
>>
>> <http://stackoverflow.com/questions/31133603/in-postgresql-weird-issue-about-citext-performance>
>>
>> though that’s not specific to indexing that column type.
>>
>> (Finally, if you are using PostgreSQL, and you do need to add this extension
>> to an existing database during a migration, there is a small issue with the
>> JDBC info not being available to EOF quite early enough, which is easily
>> fixed. I can dig up the thread if you need it.)
>>
>>
>> --
>> Paul Hoadley
>> http://logicsquad.net/ <http://logicsquad.net/>
>>
>>
>> _______________________________________________
>> 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/maik%40selbstdenker.ag
>>
>> <https://lists.apple.com/mailman/options/webobjects-dev/maik%40selbstdenker.ag>
>>
>> This email sent to m...@selbstdenker.ag <mailto:m...@selbstdenker.ag>
>
> _______________________________________________
> 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/jeffschmitz%40icloud.com
>
> <https://lists.apple.com/mailman/options/webobjects-dev/jeffschmitz%40icloud.com>
>
> This email sent to jeffschm...@icloud.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
