A lot of documentation on views mentions a "Case" dropdown which allows case transformations on taxonomy name arguments to be done before the arguments are used.

I don't see the option on 7.x-3.x although the checkbox for space/dash transformation is there. I also don't see the any mention of case transformation in the code that does the validation.

Has the option been dropped from 7, and if so what else can be done to make lowercased strings work for the "Term name converted to Term ID" validation type?

Comments

bojanz’s picture

Yes, case sensitivity has been removed.
It never actually worked right across databases...

Can you give an example of what you're trying to do?
You can probably do what you need through the PHP code validator.

dawehner’s picture

Status: Active » Postponed (maintainer needs more info)

Just for documentation.

esmerel’s picture

Component: User interface » Documentation
Status: Postponed (maintainer needs more info) » Active
merlinofchaos’s picture

This was removed? How strange. Why?

bojanz’s picture

Becase DBTNG assumes case insensitive like (since case sensitive like only ever worked on Postgres).

merlinofchaos’s picture

Does this mean DBTNG forces case insensitive compares on postgres?

It's kind of a strange thing. With MYSQL, case sensitivity depends on the collation. Normally, we use utf8_ci which is case insensitive, but it could easily be collated with something else which is case sensitive.

Postgres is case sensitive by default.

That code just threw a LOWER() onto both sides of a comparison. I can't believe that's no long applicable in cases where postgres is in use, or the very very rare case that someone has changed the collation on mysql.

bojanz’s picture

Does this mean DBTNG forces case insensitive compares on postgres?

Yes.

merlinofchaos’s picture

Huh. Seems like that'll totally screw over a bunch of indexing. :/

bojanz’s picture

Status: Active » Fixed

I'm wrong since January 3rd.
We never removed the Case dropdown in arguments, only the Case checkbox in filters. It's two very different things.
I see the code in views_handler_argument_string, so all handlers that inherit from it should be fine.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.