Developers of Sympa

[David Verdin <address@concealed>]

Hi all,

Le 08/01/13 05:33, IKEDA Soji a écrit :

Dear all
A happy new year!

Thanks Soji, a happy new year to you too!

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.

Yes, we could support multiple granularities: full table for creation and atomic modification for upgrades.

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.

It looks promising indeed. Does anybody know whether this module uses precompiled statements for select and update queries? I'd really like to generalize this practice as it is supposed to greatly improve database usage performances.

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?

Where is this coverage specified? i did'nt see it in the CPAN page... Or maybe I still have too much Champagne in my blood after new year's eve...

Cheers,

David

Regards,

--- Soji

Attachment: smime.p7s
Description: Signature cryptographique S/MIME