Developers of Sympa

[IKEDA Soji <address@concealed>]

Dear all
A happy new year!

On Thu, 27 Dec 2012 19:30:44 +0100
Guillaume Rousse <address@concealed> wrote:

> Le 18/12/2012 16:46, IKEDA Soji a écrit :
> > Hi developers,
> >
> > By now, I am debugging Sympa with MySQL (mainly 5.5 and sometimes
> > earlier), Pg (only 9.1) and SQLite (3.7.7; current code won't
> > support SQLite 2.x).  They are working nice or so.
> >
> > Oracle, Sybase (and MS-SQL/ODBC and Informix and..., and..., more!)
> > has not been checked by me.
> >
> > What kind of RDBMS(es) you are using for debugging and coding?
> I just commited a bunch of tests for those different RDBMS in my branch.
> 
> Only mysql and sqlite do actual database interaction tests, whereas 
> other just test the statement generation methods.I should add 
> interactions test with postgresql quite easily soon, and eventually port 
> the whole stuff to Test::Database rather than rely on environment 
> vaariables.
> 
> Anyway, those tests quickly show than trying to produce specific SQL 
> statement isn't enough to ensure complete transparency, as underlying 
> features seems to differ quite a lot between various RDBMS. For 
> instance, sqlite has very limited support for table modifications, 
> meaning deleting fields or adding primary keys after table creation 
> won't work...

You are right.  On current 6.2 branch the SDM component for SQLite
exactly do it.

> So, rather than the current API granularity, allowing to create an empty 
> table and populating it in a second time, it would seems safer and more 
> portable to be able to passe a fields list definition to add_table() 
> method. Additionaly, it would avoid the ugly 'temporary' field hack :)

Current step-by-step construction is ugry.  But anyway, addition and
deletion of fields/keys are nessessary for upgrade process.

> And before Marc jumps on the subject, it may be interesting to look for 
> already existing perl ORMs, rather than reinventing the wheel. Whereas 
> Class::DBI or Class::DBIx are definitively overkill, lightweight 
> alternatives as DBI::Skinny would seem a good compromise between 
> additional dependencies and maintainance gain.

They seem the wheels and the axles we have desired.

One of issues may be coverage of DB engines (e.g. D::S doesn't
support Sybase and Informix).  Should we make decision to
continue or to abandon development of any of RDBMS support?

Regards,

--- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/