Re: Re: [Axiom] PostgreSQL backend incompatibilities

Dnia Friday 06 January 2006 05:14, [email protected] napisał:
> Let me just fill in the others watching this discussion as to what has
> transpired behind the scenes :).
>
> Commercially speaking - and this is very important, as you must understand
> that Divmod is a tiny company with no money that already spends more time
> than our investors are altogether comfortable with contributing to open
> source - Divmod has no interest in supporting alternative database
> backends.
>
> We are going to run our service on SQLite, and SQLite has proven to be a
> *VERY* nice piece of software.  Therefore, spending our scarce resources
> (such as my time) to make database portability happen is unlikely.

As I wrote before, I'll write this again: I think I understand Divmod's goals.
As I remember the database backend situation like it was some time ago, I'm 
really glad to see you're making progress. I'm pretty sure, that having 
better backend software boosts the development significantly. 

With Divmod's customer base growing bigger, software and hardware requirements 
may become bigger also. SQLite is really good product, but I don't think 
anyone should consider it equal to a real RDBMS. What you should remember 
about is, that even if it gives Divmod enough power today, it may not be 
sufficient tommorow. There is a number of features in PostgreSQL (not to 
mention Oracle), that you can find useful - which are not present in SQLite. 
In the future, Divmod may hit some SQLite limitation and by that time it will 
be obvious, that another DB backend should be used. If Axiom will be tied too 
closely to SQLite implementation, the transition to another backend could not 
be possible.

Having this in mind, I think it's not a bad thing to rip off SQL generation 
from Axiom to another module and make different DB backends pluggable. In 
fact, I'm already working on this; when my implementation will be clean 
enough, I'll submit a patch to the tracker - possibly with APSW support, as 
you said it could be useful for Divmod.

> So, the sqltype should be a constant.  There should be a backend-neutral
> module that provides an interface between implementation modules such as
> item, attributes, and store, and the actual backend that was selected.  The
> actual backend in use will know about the list of supported types, and it
> will check against the list provided in the aforementioned backend-neutral
> module.
>
> So for example:
>
> from axiom.datatypes import UNICODE_STRING
>
> class text(SQLAttribute):
>     texttype = UNICODE_STRING
>     def getDataType(self):
>         return texttype

Yep, that's definetley a good idea. I've used it already to rip off SQL 
generation out of Comparable attribute, so it now returns overlay objects 
which are then flattened in the backend module. With this in mind I think, 
that having non-SQL backend would be possible.

> I believe you do, although I don't know if you have permission for the full
> repository.  If you don't, we should add you back to it though: pretty
> soon, there should be a branch in the repository as well as tickets in the
> tracker, as I suspect this will be a pretty major undertaking (and it
> sounds like at least dialtone would be interested in helping).

Thanks. My own branch in Axiom repo would be enough. I must rethink the SQL 
overlay objects layout and clean up the patch a bit, and, after I have 
something to show to the world, I'll accept any help required. And, in return  
for the time spent on taking care of this issue (review, suggestions), I'll 
make sure the patch contains APSW backend.

-- 
Michal Pasternak