-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregor,
Gregor Schneider wrote: | Sure, there are a lot of possible solutions, however, it would ease up | things if MySQL would behave as expected by the "common programmer". Sorry, but the "common programmer" ought to know that, in spite of SQL's "standard-ness", every RDBMS implementation is slightly different. Just try to do something as simple as getting the database to generate a unique id for you, and suddenly you are outside of the standard. http://en.wikipedia.org/wiki/Sql#Reasons_for_lack_of_portability | Just an example: | | What, if you create a databse-independent software (as what we do), | that runs on any database providing a JDBC 2.0-compliant driver and | supports SQL 2.0-standard? You probably mean something like SQL-92. Or maybe SQL3? FIPS 127-1/SQL-89? The problem is that SQL is not as standard as you think. Sure, some group of people sat in a room and made some decisions, but the database companies also made different decisions. | AFAIK DB2 doesn't know the binary attribute, not sure about Oracle, | Postgres, Informix etc. No, they have other ways of doing this. See http://www.orafaq.com/node/999 for instance. SQL Server has the same semantics as MySQL ('=' is case-insensitive). It's all over the map. Remember that JDBC is a method-oriented API, but does not make any assumptions about the underlying implementation. You are free to call (SQL) functions that only exist in certain databases and not in others. Want string concatenation in Oracle? Use ||. Moving to another database? Well, you're gonna have to change all those to something else (usually a function call). There are many many many examples of this. | So what you'd have to to then is evaluate every database for those | kind of "features" and provide different create-scripts for each | database providing such a "feature". Absolutely. This is the name of the game when using RDBMSs. Sorry to burst your bubble. | No problem if MySQL would offer this behaviour as a feature (i.e. | create table foo (bar varchar(10) NOCASE)), but how they did it ist | just the wrong way round, IMHO. That's exactly what they did... you just don't like the way they spell NOCASE. | Anyways, I guess we're getting slightly off topic here. To get back to | the topic, I'm wondering how many percent of the Tomcat-users using a | MySQL are aware of the fact that the user-id is not case-sensitive, | when they use a JDBC-realm as their user-database. On our projects, we don't use Tomcat realms, but we definitely see the case-insensitivity of usernames as positive behavior, since we tend to use email addresses as usernames. Email addresses are, by definition, not case sensitive, so making usernames match those semantics is good for us. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgu5joACgkQ9CaO5/Lv0PCqrQCfeXo1a9Bdty3XxCc0B9L5pGHM fHkAn0fFkwpFv5gqbuchJs1GdjXFcI8M =TPey -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
