Slashdot Mirror
MySQL Gets Functions in Java
Java Coward writes "Eric Herman and MySQL's Brian "Krow" Aker have released code to allow the DBMS MySQL to run Java natively inside of the database. The code allows users to write functions inside of the database that can be then used in SELECT/INSERT/UPDATE statements. So when will someone do Ruby?"
Now how about a way to do online backups of the new table types with out having to buy a license to do it?
I wonder how this affects performance especially compared to regular user defined functions? (Available in later releases of MySQL). This is indeed an interesting twist. It certainly can help speed up development of large projects (java works well in a large/many programmer env.) Like a lot of other tools, it remains to be seen how people put this to use. Too often people learn one thing, and like the saying goes, when all you have is a hammer, every problem looks like a nail. Lets see where this goes shall we?
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
So when will someone do Ruby?
Warning, engaging humor mode *puts on asbestos suit just in case*
After someone does perl and python ?
(notice that both of those languages, as well as tcl, are already included in the other free database project: postgres)
The Army reading list
I don't know why everybody wants to keep distance from Java. It is a very nice language implementing the very well the OOP paradigm.
The 'lusers' may not use this new feature but Java programmers will and hopefully will enjoy it.
I used Java stored procedures a lot back when I was working at a .com. For someone who's already using Java its a lot easier than learning each database vendors proprietary language. It's also good for keeping MySQL feature competitive with open source dbs, since Java stored prcedures have already been implemented for PostgreSQL
Did you not think about that post? Sounds like you just dislike Java so much that hearing it in the same sentance as MySQL makes you cringe.
1) Java isn't going to slow down any queries unless you use Java functions.
2) What do you care that someone else isn't smart enough to write good software?
3) MySQL as it stands has no other way to really embed functions easily, and it's actually more effecient to run code on the server and transfer data back afterwords.
Karma Clown
I care because when you have 200 shared hosting accounts on one server all it takes is one idiot to load things down.
Most of the time we detect who it is and suspend their account, but I still wouldn't want them running java code inside mysql.
The thing no one seems to have mentioned is that Oracle already does this and has for many years. I can't find any docs on it off-hand, but I know you can just drop a .jar file into Oracle and it will let you do similar stuff. This is nice because it lets you use a common language for doing your stored procedures instead of learning a different language for each database (e.g. Oracle uses PL/SQL).
People who are saying "what's the use of this" or "This is just going to bog down the database" most likely have never worked in the industry. Stored procedures are a very common part of large systems and adding this functionality to MySQL will go a long ways in promoting MySQL use in bigger companies.
As an Oracle DBA, at a small company, we're constantly looking for less expensive SOLID alternatives to our traditional Oracle/Solaris approach to the back end.
...
When I say solid, I mean is able to handle very large files (excess of 50GB per datafile), has stored procedures and trigger infrastructure (a traditional MySQL weak point, and the main reason we've passed on it so far), an integrated backup system a la netbackup/RMAN, and prefereably a back end compiled scripting solution a la PL/SQL.
This looks like a sorta kinda solution to the last (PL/SQL alternative), but I'm curious to know about the rest, and also how it performs. Ideally for us, we'd also like to see better clustering and large system support examples in the real world before we embarked onto this particular voyage with.. say a production ERP system.
Are we talking about a good replacement for Access or for DB2 here?
Enquiring minds want to know
-chitlenz
Imagination is the silver lining of Intelligence.
> whole new JVM on every hit?
No. Look at judf.cc. There's a judf_init and a judf_deinit. judf_init starts up the VM and hangs on to it in here:Seems to make sense - start the VM once, call it as many times as you want.
The Army reading list
"The ability to write stored procedures in Java has been in Oracle for some time but I still cannot figure out why anyone would do that."
Here are some reasons:
1) Java runs _way_ faster than PL/SQL. This is because lots of people have been working in making Java run very efficiently compared to PL/SQL. I've seen people port from PL/SQL to Java stored procedures justified purely by increased system performance.
2) It allows for consistent coding between database-resident and application server-resident code. This means that you don't need to train people in two very different languages to get work done.
3) It allows for code portability between the database and application-server. This lets you tune performance. For example, if you have some code that does tons of database I/O, it may run far more efficiently inside the database rather than accessing the database across a network.
I don't know how well the MySQL guys integrated Java yet, but in Oracle it's pretty wonderful compared to using their weird, slow, proprietary language.
Enable 3D printed prosthetics!
We all don't like learning the database language of a database. It's annoying that oracle, sybase, postgresql and mysql support different sets of ansi92 (or 98) sql, but they all have different gotchas..
limiting the # of rows of output is different between oracle, sybase and postresql/mysql.
None of them even have remotely the same stored proc language. Of course, everyone may embed a different language, but java seems to be a more common one.
Now when you go from sybase to oracle, you don't have to worry so much about the stored procedure code, since it'd all be in java anyway.. riight?
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
i will as soon as i can get her to drink this liter of vodka.
pr0n - keeping monitor glass spotless since 1981.
The knees jerk so fast on /. whenever Java is mentioned, in any context, that I'm surprised someone doesn't have their eye put out.
Of course there exist myriad reasons why one would prefer to standardize on a common language for DB SPs. Java, in this regard, is the most mature alternative at present. Even the notoriously skeptical Thomas Kyte and the pontificating Steven Feuerstein see the validity of Java in the database at the SP level.
Of course, *we* can all keep fighting amongst ourselves about such things while Visual Basic and C(flat) become the only languages we have to chose from for everything we endeavor to do.
There's similar functionality s/java/php/g, here:
http://talks.php.net/show/phpquebec/27
http://www.sklar.com/page/article/myphp
S
This is all about writing functions, like no_null in
MySQL has always had an expansion framework for adding you own functions to the SQL, it's just that traditionally you had to have a compilable language to do that. Now, you can use Java methods as well. (Still not a bright idea IMHO, but...)
I choose to remain celibate, like my father and his father before him.
So when will someone do Ruby?
Not soon. Ruby cannot be embedded in a threaded application without using a giant mutex. Only one thread at a time can call Ruby interpreter.