----- Forwarded message from Steven Ovits <[EMAIL PROTECTED]> -----
Date: Wed, 17 Oct 2007 21:02:14 -0400
From: Steven Ovits <[EMAIL PROTECTED]>
To: sqlobject-discuss@lists.sourceforge.net
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Imdbpy-devel] MS SQL Server
X-Mailer: Microsoft Windows Mail 6.0.6000.16480
I'm new around here, and don't know Python or the SQLObject api, so I
apologize if this is useless or goes against the goals of SQLObject. It
seems to me that trying to do version-specific things for particular
databases is like opening a large can of worms. Once you open it, there's no
putting them back. If you haven't gone there yet, trying to find a different
approach might make more sense.
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.
Each might have a different maximum length for varchar, and support the text
type or not. (The text type is deprecated, so version 10 might not support
it.) More problematic is that the maximum size of a varchar column depends
on other things besides version, such as how much other data is in the
column and whether the "text in row" option is on or off. This isn't just an
mssql issue--the same kind of thing happens in other databases.
Do you want to support this kind of thing for Oracle? Db2? All the other
databases? What about standard SQL, which has always been more a myth than
reality. Is it DELETE table or DELETE from table? 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. These
wouldn't be derived from the core classes, but still work with them. Treat
them as user submitted, unsupported tips, utility functions, suggestions,
FAQ, etc, but written as separate code files that users can use in addition
to the supported core.
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, even things like tsql or java, two other things are important. The
database connection needs to be usable from code that doesn't use SQLObject.
This might need to be done in the other direction, where the user passes in
the connection they create somewhere else. I had to allow this in an inside
an ODBC/OpenX api in order to support DB2 embedded SQL, because embedded sql
requires the connection to be created through the embedded SQL api. The
second thing that need to be shared like this is transactions. Users should
be able to mix the two types of code within a single transaction. Beyond
this, it's a matter of choosing what you can reasonably support.
This kind of approach frees you from maintaining all kinds of feature
requests, but still allows users to do anything they want. You don't need to
support all these things, but you also don't prevent users from doing the
hard things themselves. If there's enough "user-supported" code from
different databases to make it easy to move it into the core, that's great,
but doing that also means having to maintain it in the future.
>Message: 9
>Date: Wed, 17 Oct 2007 17:02:20 +0400
>From: Oleg Broytmann <[EMAIL PROTECTED]>
>Subject: Re: [SQLObject] SQL Server varchar(4000) instead of TEXT
>To: sqlobject-discuss@lists.sourceforge.net
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=us-ascii
>
>On Wed, Oct 17, 2007 at 02:45:24PM +0200, Davide Alberani wrote:
>>2007/10/15, Oleg Broytmann <[EMAIL PROTECTED]>:
>>> How can I ask the version of the server?
>>
>>See these instructions (again suggested by Steven Ovits):
>> http://support.microsoft.com/?id=321185
>
> Thank you. That is, if I need to test if SQL Server support MAX-types,
>I have to try to issue the query
>
> SELECT @@VERSION
>
>If it fails - it is SQL Server 2005. If the query returns a result - I
>have
>a server version 5.0+, and any version of it supports MAX-types.
> Right?
>
>>I'm more and more persuaded that the "S" of "SQL" means "Structured" and
>>not
>>"Standard". ;-)
>
> Could it depend on the previous letters? If the letters are 'M' and 'S'
>- does it make things better or worse? ;)
>
>Oleg.
>--
> Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED]
> Programmers don't die, they just GOSUB without RETURN.
----- End forwarded message -----
-------------------------------------------------------------------------
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
