Hi Steve,
Thanks for your feedback, this is helpful;
Steve Toback wrote:
On 9/18/06, Ludovic Maitre <[EMAIL PROTECTED]> wrote:
I have ported the tables.sql, procedures.sql, views.sql files to MySQL
5.1, but i cannot port the functions because they use a REF CURSOR as
return value, and this is only supported by Oracle AFAIK (i guess i can
deal with the types defined in packages.sql, these are not supported
obviously in MySQL but this can be tackled at a higher level (java
code)).
Most of the current stored procedures actually don't need to be stored
procedures, as they're just simple selects.
Great, i will have no difficulty to finish the work,
So i have began to dig into the code of Lokahi ... are the classes
org.apache.lokahi.core.common.database.[Derby|Oracle]Broker designed to
hide the databases particularisms ? ...
The Adminbean / current controller thread is an ugly way of getting
one instance of Lokahi's controller to not step on another. I'd like
to replace them that uses the custom database broker classes we have.
Ok, i will code in this direction,
We haven't talked about implementing an existing framework, that would
take quite a bit of refactoring to accomplish.
It's better, so your mind is open for any framework :-) Effectively the
most important is to have a functional Lokahi with MySQL and other DBs
which doesn't support the exotic features of Oracle: this could drive
more people to use the software, and i hope more devs, so i will not
have to code myself the features i would like to have :-) [i mean
managements of Dbs and other types of servers, something generic which
could complement a continuous build system (like my CruiseControl ;-)].
Also this is a lot of work it seems to use a framework right now, but
i'm sure you know this better than me!
Best regards, glad to have your advices,
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
