Hello!
On Wed, Oct 17, 2007 at 09:02:14PM -0400, Steven Ovits wrote:
> I'm new around here
You are welcome!
> seems to me that trying to do version-specific things for particular
> databases is like opening a large can of worms.
Why? SQLObject already has version-specific code for Postgres - it
distinguish Postgres before 7.2 and after it. Now, when Postgres is at
version 8.3, we could remove that part. But it didn't cause us many
troubles.
> For mssql, if SELECT @@VERSION returns something, it's either version 6.5
> or 7.0. SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY
> ('productlevel'), SERVERPROPERTY ('edition') works for versions 8 and 9.
We only need to distinguish MSSQL 5 from the later versions because we
only want to use VARCHAR(MAX) instead of TEXT and VARBINARY(MAX) instead of
BLOB.
If have any expertise in this - please help.
> Do you want to support this kind of thing for Oracle? Db2? All the other
> databases?
Why not?
> What about standard SQL, which has always been more a myth than
> reality. Is it DELETE table or DELETE from table?
Along with the core classes SQLObject has database-specific classes. All
backend-specific tricks go there.
> A different approach
> might be more productive. Personally, I think you should limit the
> database-independent support to the minimum you can reasonably support
> that's also widely used. The extra things can go into the database-specific
> files. I'd even separate the core database-specific files and keep these
> half supported things in separate files, such as mssql.utils.py.
SQLObject does exactly that. The code is in
sqlobject.mssql.mssqlconnection module. The only but rather big difference
is that the code is integrated with SQLObject, and is supported.
> Some things belong in the core. In addition to alowing some way for users
> to specify database-specific data types and execute arbitrary
> database-specific sql
SQLObject doesn't prevent this. Any user can execute raw SQL. But
they don't want to, because that means the user have to work with
3 different languages - Python, SQLObject and raw database-specific SQL. In
such cases users usually prefer to drop ORM so they only have to use two
different languages. I'd like to allow users to use two languages - Python
and SQLObject. ;)
> This might need to be done in the other direction,
> where the user passes in the connection they create somewhere else.
That would be hard to implement because connections in SQLObject are
SQLObject-specific, too. SQLObject maintains a pool of connections it has
opened, a cache for an every connection - it has to manage DB API
connection itself.
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
