Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
It remains a functional relational database. It has a BSD-style license with a very stable, nearly bug-free (see Coverity) core. It has modular design (you can write procedures in Java, C, C++, T/SQL, R, Python and others. You can get commercial support from a company (EnterpriseDB) that doesn't have a vested interest in moving you to a very expensive alternative.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
mysql> create table foo(bar varchar(10)); mysql> insert into foo (bar) values ('abc'); mysql> select * from foo where bar = 'abc'; +------+ | bar | +------+ | abc | +------+ 1 row in set (0.00 sec)
mysql> select * from foo where bar = 'aBC'; +------+ | bar | +------+ | abc | +------+
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
And this is why you don't do the string comparison on the database side. SELECT hash FROM users WHERE login = [the entered login] and then, in your application, hash the entered password and compare the strings. Problem solved (before it began!). If your app is doing the comparison in the database, it's your own fault.
(This also has the advantage that the hash of the entered password never travels over the wire (if your db server is on a different box). Granted, that would only be a problem if your network
What about MySQL? (Score:5, Interesting)
Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
Postgres is looking better than ever (Score:5, Informative)
Re: (Score:1)
Re: (Score:1, Insightful)
Their string comparisons are case sensitive.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
Re: (Score:1)
And this is why you don't do the string comparison on the database side. SELECT hash FROM users WHERE login = [the entered login] and then, in your application, hash the entered password and compare the strings. Problem solved (before it began!). If your app is doing the comparison in the database, it's your own fault.
(This also has the advantage that the hash of the entered password never travels over the wire (if your db server is on a different box). Granted, that would only be a problem if your network
Re:Postgres is looking better than ever (Score:2, Insightful)
This also has the advantage that the hash of the entered password never travels over the wire (if your db server is on a different box)
Umm... and the actual correct password hash traveling over the wire as a result is better how?