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.
So i have began to dig into the code of Lokahi and i see some hardcoded references to Oracle in org.apache.lokahi.core.controller.AdminBean. Before hacking this file (and the other ones which will exhibit the problem) so it doesn't use a sql function which return cursors, i would like to know what are the plans regarding the support of other dbs than Oracle (well there is a support for Derby that i haven't tested but i focus on MySQL and would like to help develop to support it -> i'm wondering if the derby support is functional even with the references to OracleTypes in Adminbean?), because perhaps you have already defined something. For instance, are the classes org.apache.lokahi.core.common.database.[Derby|Oracle]Broker designed to hide the databases particularisms ? Are you planning to use an existing ORM framework in the future so you will not have to support yourself the db part for each server ? (My personal preference go to OJB, but any framework would be interesting (hibernate...)) If this is the case have you a preliminar design ?
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. We haven't talked about implementing an existing framework, that would take quite a bit of refactoring to accomplish.
