Re: [Planner Dev] MySQL tables
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: Alvaro del Castillo <acs barrapunto com>
- Cc: Planner Project Manager - Development List <planner-dev lists imendio com>
- Subject: Re: [Planner Dev] MySQL tables
- Date: Sat, 07 Feb 2004 15:20:13 +0100
On Sat, 2004-02-07 at 10:56 +0100, Alvaro del Castillo wrote:
> Hi guys!
>
> El sáb, 07-02-2004 a las 04:04, Richard Hult escribió:
> > tor 2004-02-05 klockan 08.44 skrev Lars Brandi Jensen:
> > > Hello
> > >
> > > I have made a draft for MySQL tables. It is importing well to MySQL
> > > 4.0.1, but I know there is something new in 4.1.0 like support for
> >
> > Thanks!
> >
> > > boolean. A review of the structure would be nice :
> >
> > Any MySQL experts here? :)
> >
> > I'm not sure what the next step is. Perhaps to unify the both schemas
> > somehow and try to move the gda code to not use vendor specific
> > features? Alvaro, do you have any hints? :)
>
> Actual SQL code isn't usable in MySQL with widely used versions (3.x.x).
> It uses CURSORS in lots of places, something that MySQL doesn't have. I
> am not an expert in MySQL so maybe I could be wrong, but for use MySQL
> as storage backend we have to modify a lot the to MySQL code.
>
> In next versions of libgda, 1.2 I think, the CURSOR (and other things)
> code will be embedded in the library, so you can safely don't use cursor
> and let libgda to manage this kind of things.
>
right, but that will be in 1.2. So, while still using 1.0.x, I would
suggest you try to use as generic SQL as possible, so that it can work
with all DBMS.
Also, 1.2 will provide a simple way of creating tables programatically,
without SQL at all, so that should help also on reducing all the
specific SQL.
> So we have paths right now:
>
> - Start simplifying the SQL code, something that could be good thinking
> in libgda 1.2, so we can start using the MySQL database.
>
> - Wait until libgda 1.2 hits the streets and convert the SQL code. I CC
> Rodrigo Moya, the mantainer and project leader of libgda, so he can
> guide us in this decission.
>
the 1.2 work in the API is done, we are only missing the implementation
in the providers, so the work involved there is quite small, specially
if we concentrate only on the most used DBMS, like Postgres and MySQL
[1]. Lack of time has been the only issue preventing this to be
implemented. For Postgres, a guy is supposed to be working on it, so
could be implemented anytime. As soon as that is implemented (for at
least a couple of providers) we might start releasing 1.2 beta releases,
and probably will be freezing soon after that.
cheers
[1] BTW, we've got a licensing problem pending resolution with the use
of MySQL > 3.3.x, since the libs are now GPL, while libgda is LGPL. We
are waiting, along with other projects, on an answer from the MySQL guys
to see what we can do. Right now, the MySQL provider is disabled in CVS
until this is resolved.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]