SQLServer Updates?
prote...@gmail.com
) with interest and have even emailed a few people listed as
participating in this effort but have not been able to get any sense
of how/if this is coming along. I've even offered to provide dev/test
assistance but received no responses to my recent emails, alas.
My team is developing our organization's first python/django/soa
application and, unfortunately, must deploy in a windows environment
(we'll fix that issue later). For now, we're developing on top of
Postgres but our IT infrastructure is not prepared to support a
Postgres deployment (much less linux) and is *strongly* encouraging us
to deliver on top of SQLServer. If it's at all possible we want to
comply with this request therefore I am offering help on getting this
feature working cleanly on top of .96 if it is something that can be
reasonably accomplished in the near term (demo fast and deploy in few
months max).
I'd appreciate any help from people knowledgable about this effort and
look forward to working with them and my staff on getting this
production ready. I think being able to demonstrate full windows
support for deployment will go a long way into assisting organizations
such as ours that wouldn't otherwise get the opportunity to try python/
django at all. Call it a gateway drug to Open Source addiction... :)
-- Ben
PS: We're also having to use IIS and would be happy to discuss
experiences with others. We've actually got a "solution" for now but
am always interested in alternatives or helping others with similar
afflictions.
prote...@gmail.com
offer basically expires today because I have to go to my management
with a recommendation for deployment. There hasn't been any updates on
ticket 2358 (except to say don't ask for when its going to be done -
ask in django dev instead which I did) and emails I've sent to
participants of that ticket have not been returned.
Understand that I don't feel entitled to a response, just that I
figured if *I* were working on or interested in SQLServer support for
Django I would act on my own enlightened self-interest and take up the
offer for assistance immediately. This has led me to conclude that
there simply is no serious interest at this time and that my
organization would pretty much be left with the task of keeping such
support current with Django modifications. Such is the nature of Open
Source projects and the risk of being early adopters some times, alas.
We did perform some analysis of the code submitted thus far but
determined that some fairly basic mappings were simply not present.
For example, SQLServer has a bit field rather than a boolean so only
accepts a 1 or 0 value but the current Django/SQLServer code attempts
to send True or False which fails. It appears that some tables don't
get autoincrement ids whereas some do (haven't investigated why).
Additionally, Time/Date formats are all incompatible with SQLServer so
it doesn't appears the current effort has gotten far enough to be
considered basically functional much less ready for production use.
Note that these aren't complaints, but rather an attempt to inform
others who are interested in SQLSupport as users as to the current
state of the patch. It's not nearly ready and seems to have stalled
for now. I'm still hopeful for the future but don't expect to see this
thing moving until some more public activity shows up on it.
Meanwhile, I'm very happy to see that the Oracle port has gone very
well and seems to have the necessary support to keep it going in the
future. I still think support for these proprietary databases is a
great way to get python/django/oss into the enterprise and
congratulate the team on their success.
-- Ben
Jeremy Dunck
>
> Replying to myself because I'm the only one that will. :)
Sorry, I actually meant to respond but it dropped of my radar.
> So this
> offer basically expires today because I have to go to my management
> with a recommendation for deployment.
Over the time I've been involved with Django (something like 1.3
years), there's been a large number of requests for SQL Server
support. At PyCon 2006, I tried to consolidate the various patches
into a usable solution, but the lack of LIMIT/OFFSET support in SQL
Server 2000 stymied me. Pagination is vital in Django.
(I recall Matt Good made some separate progress, but I'm not sure what
became of his work.)
Another thing that I found, at the time, IIRC, was that adodbapi and
pymssql each made different design tradeoffs in trying to comply with
the DB-API while dealing with gaps in how SQL Server actually works.
pymssql seemed the better choice since it has cross-platform support
and would better serve the typical linux/apache deployment.
Additionally, the maintainer (Andrzej Kukula <akukula gmail>) of
pymssql was responsive.
(Reviewing the change log on pymssql, I see Joseph Kocherhans, now a
Django committer, had a run in with pymssql back at 0.7.1).
That said, I was doing it out of general interest rather than personal
itch, and my enthusiasm faded, especially since I no longer personally
use SQL Server. I'm sure the problems are surmountable, especially if
we wait long enough for SQL Server 2005 to become the norm. ;)
> This has led me to conclude that
> there simply is no serious interest at this time and that my
> organization would pretty much be left with the task of keeping such
> support current with Django modifications. Such is the nature of Open
> Source projects and the risk of being early adopters some times, alas.
This is kind of sad; as I said, I'm pretty sure there would be
interest if there were support, but because it's not there, those that
would use it wander off to use some other tool. Not that I'm trying
to guilt you-- just that I might some day also wish again for SQL
Server support. :)
...
> For example, SQLServer has a bit field rather than a boolean
Hmm. I actually would have expected the DB-API to take care of that
kind of detail. I'm pretty sure Andrzej would be happy to accept a
patch to pymssql._quote and pymssql.pymssqlCursor.executemany to
handle the bool<->bit mapping.
> It appears that some tables don't
> get autoincrement ids whereas some do
Odd. :)
> Additionally, Time/Date formats are all incompatible with SQLServer
Actually, pymssql does seem to handle datetime formatting properly.
> Note that these aren't complaints, but rather an attempt to inform
> others who are interested in SQLSupport as users as to the current
> state of the patch. It's not nearly ready and seems to have stalled
> for now.
I see the ticket patches are around adodbapi. That's a mistake, IMHO,
but I haven't had the need to make a new patch around pymssql. Sorry.
:(
I will comment over on the patch to this effect, but I doubt I will
have much affect until I provide an alternate patch.
> Meanwhile, I'm very happy to see that the Oracle port has gone very
> well
Yep, and some of the new flexibility in there may help with SQL Server
in the future. They did some good stuff there.
> I still think support for these proprietary databases is a
> great way to get python/django/oss into the enterprise and
> congratulate the team on their success.
I still hope to liberate lost souls. ;)
I try to look at this situation as glass half-full. Django wouldn't
exist at all without everyone having some common interest but personal
itches. Any time someone has a complaint of a missing feature, they
have the chance to make a case for the feature and to improve Django's
reach because of it. It's too bad that not everything I want is there
already, but I get more than I give (by far). I used to be in
corporate IT working with proprietary MS and Java stacks. I know the
need.
Would you be using SQL Server 2005? If so, I think a patch supporting
only SQL 2005 is fairly straight-forward and perhaps enough to draw in
people to do their own SQL 2000 thereafter.
Sorry if I missed the opportunity to guide your enthusiasm. I
understand your reluctance to take on the commitment the Boulder PUG
has made for Oracle.
-Jeremy
Russell Keith-Magee
> figured if *I* were working on or interested in SQLServer support for
> Django I would act on my own enlightened self-interest and take up the
> offer for assistance immediately. This has led me to conclude that
> there simply is no serious interest at this time and that my
> organization would pretty much be left with the task of keeping such
> support current with Django modifications. Such is the nature of Open
> Source projects and the risk of being early adopters some times, alas.
Hi Ben,
Apologies that you got _no_ response - this one obviously fell through
the cracks.
Your analysis is pretty much dead on. An ADO backend exists, but as
you noted, it has problems. While there is the occasional nibble of
interest for SQLServer support, there are many other features that are
requested more often. To the best of my knowledge, nobody is working
on the problem at the moment.
As with all open source, things only get done if people care to do
them. Oracle support has only occurred because of a very dedicated
group putting in some serious effort, initially over a sprint, but
also committing to long term support. If someone were to offer an
equivalent effort for SQL Server, they certainly wouldn't be turned
away.
However, in the absence of a third party offering fixes, i wouldn't
count on SQL Server support in the near future.
Yours,
Russ Magee %-)
pk11
I have a semi-working* pymssql patch if anyone interested.
*= everything is working except: OFFSET (which is tough problem for MS
SQL server) and the dbshell option for the manager but i believe that
does not work for ADO as well.
The reason why I did not release it is because at the moment I just
overwrote ado_mssql driver.
and since ado_mssql is hardcoded a lot, I did not want to hardcode a
secondary mssql driver name.
peter
On Apr 20, 10:39 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On 4/20/07, proteus...@gmail.com <proteus...@gmail.com> wrote:
>
>
>
> > Understand that I don't feel entitled to a response, just that I
> > figured if *I* were working on or interested inSQLServersupport for
> > Django I would act on my own enlightened self-interest and take up the
> > offer for assistance immediately. This has led me to conclude that
> > there simply is no serious interest at this time and that my
> > organization would pretty much be left with the task of keeping such
> > support current with Django modifications. Such is the nature of Open
> > Source projects and the risk of being early adopters some times, alas.
>
> Hi Ben,
>
> Apologies that you got _no_ response - this one obviously fell through
> the cracks.
>
> Your analysis is pretty much dead on. An ADO backend exists, but as
> you noted, it has problems. While there is the occasional nibble of
> interest forSQLServersupport, there are many other features that are
Ian Holsman
> Understand that I don't feel entitled to a response, just that I
> figured if *I* were working on or interested inSQLServersupport for
> Django I would act on my own enlightened self-interest and take up the
> offer for assistance immediately. This has led me to conclude that
> there simply is no serious interest at this time and that my
> organization would pretty much be left with the task of keeping such
> support current with Django modifications. Such is the nature of Open
> Source projects and the risk of being early adopters some times, alas.
While this may be true in the short term, you will find others who
will start to use your
SQLserver driver as time goes on and the driver is seen as stable. A
lot of people dismiss
django (or any framework) if it doesn't match their exact needs. Once
a driver is ready and stable,
you will find people using it quite happily.
The question your org should ask is... is the cost of developing and
maintaining
the SQLserver driver and enjoying the use of the rest of django
larger than the cost
of going with some other solution.
You need to evaluate how beneficial django's other features are over
it's competition.
The cost of supporting SQLserver might be very small compared to you
guys writing all
your code in .NET/C#, or purchasing a commercial alternative.
regards
Ian
--
Ian Holsman
I...@Zilbo.com