I need fix "non proper sql server support" in the next 3 weeks. What is next?
mamcx
Is a must, a requeriment for delivery. So, I can't wait anymore for
free open source hacking...
Like somebody can see in my history in the users group, I'm strongly
in the windows world because my company http://www.elmalabarista.com/
specialize in build tools for integrate systems, mainly local ERP/CRM
with Pocket PC devices a Web-enable this information.
My tools now are delphi and python, and the database for the mayority
of my clients are Sql server.
So, I can devote dev time to fix the non-sql server support. I have
read the code, see all the patch (and be confused for its). I'm not a
python guru but have 3 years of expertise in develop against Sql
server.
So, how proceed? To how I need to talk?
Joseph Heck
this kind of support.
My guess is you might check the development trunk
(http://code.djangoproject.com/browser/django/trunk/django/db/backends/ado_mssql)
and try it out to see if it works acceptably for you needs.
I'm sure the core maintainers would welcome any patches. I don't know
the state of current patches available in Trac, but there are a number
of tickets that would be worth reading to understand the state of the
union there (http://code.djangoproject.com/search?q=mssql&noquickjump=1&ticket=on).
-joe
Forest Bond
> I have a requeriment to support Sql Server in a outsourced contract.
> Is a must, a requeriment for delivery. So, I can't wait anymore for
> free open source hacking...
You know, I never could figure out why someone who is benefiting from an
open-source project would write to that project's mailing list (with poor
grammar, no less) and make a comment like this one. While you're here, you
might as well try understanding this open-source thing.
You clearly got part of it: if you want something done, and don't want to pay
someone else to do it, do it yourself.
It's the other part (which constitutes advice that Schwarzenegger himself might
have offered) that you seem to have missed: stop whining and write some code.
-Forest
--
Forest Bond
http://www.alittletooquiet.net
Jeremy Dunck
> On Tue, Jul 31, 2007 at 09:58:57PM -0000, mamcx wrote:
> > I have a requeriment to support Sql Server in a outsourced contract.
> > Is a must, a requeriment for delivery. So, I can't wait anymore for
> > free open source hacking...
>
> You know, I never could figure out why someone who is benefiting from an
> open-source project would write to that project's mailing list (with poor
> grammar, no less)
With respect, mamcyz is clearly not a native speaker, and I'm quite
sure (s)he writes English better than I would write her lang.
Perhaps poorly stated, but I read this to mean "OK, I know the
support's been discussed a lot, but I have a need, and would like some
pointers so I can get it done."
I didn't read it as complaining. :)
Julio Nobrega
weren't in such a hurry to give the standard zealot answer, perhaps
you could have seen it.
On 7/31/07, Forest Bond <for...@alittletooquiet.net> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGr8FFRO4fQQdv5AwRAhpNAKCPBFYZ3E2DQqYecDdsI7M9lwBeJACdFRJm
> PQkFscFmM48KdWAN4+lzNtA=
> =Urox
> -----END PGP SIGNATURE-----
>
>
--
Julio Nobrega - http://www.inerciasensorial.com.br
Jeremy Dunck
> read the code, see all the patch (and be confused for its). I'm not a
> python guru but have 3 years of expertise in develop against Sql
> server.
Start with pymssql, not adodbapi. adodbapi is not cross-platform.
Solve pagination. That is, make this work correctly:
SomeModel.objects.all()[10:20]
If you get that going, you're almost done.
:)
Forest Bond
> He's asking how to contribute with code he's going to write. If you
> weren't in such a hurry to give the standard zealot answer, perhaps
> you could have seen it.
I doubt very much the "standard zealot answer" would include reference to
Schwarzenneger. :)
None-the-less, I apologize for misinterpreting what appeared to me to be a
sneering jab at open source, amounting to little more than biting the hand that
feeds (independent of what was being offered).
Sorry, mamcx.
Joseph Kocherhans
These 2 posts are probably the best summary of the status of SQL Server support:
Which patch did you look at and what version of Django are you using?
You might be able to get some SQL Server support working in 3 weeks,
but I don't think you will be able to solve the pagination problem in
that amount of time.
Also, even if you do get SQL Server support working in 3 weeks, you
will have to maintain your own version of Django. Oracle support took
several months before it was checked into the trunk, and they had a
whole team of people working on it and committed to maintaining it.
Joseph
Jeremy Dunck
> Which patch did you look at and what version of Django are you using?
> You might be able to get some SQL Server support working in 3 weeks,
> but I don't think you will be able to solve the pagination problem in
> that amount of time.
Here, I attach a response from Andrzej, the pymssql maintainer, with
some suggestions for how to accomplish pagination using SQL Server.
---------- Forwarded message ----------
From: Andrzej Kukuła <aku...@gmail.com>
Date: Mar 2, 2006 4:34 PM
...
> The common case for LIMIT/OFFSET is pagination of query results.
LIMIT/OFFSET are by no means standard approach to the problem; they
are supported only by MySQL and PostgreSQL, and are not supported by
MS SQL, Oracle or IBM DB2.
There are 3 other methods which you can use without any change in pymssql:
1) typical MSSQL method:
SELECT * FROM (
SELECT TOP num_of_interesting_rows * FROM (
SELECT TOP num_of_interesting_rows+num_rows_to_skip interesting_columns
FROM interesting_table
[WHERE ...]
ORDER BY orderby_columns ASC
) t1 ORDER BY orderby_columns DESC
) t2 ORDER BY orderby_columns ASC
in this example t1 and t2 are dummy identifiers and can be anything;
this nested SELECT is really very efficient and is used everywhere in
MS SQL world for pagination. Remember that it's optimal only when
orderby_columns are indexed.
Pay attention that orderby_columns have to be the same in all 3 ORDER
BY clauses. Of course the innermost FROM clause doesn't have to be
that simple, you still have 29 levels of query nesting, JOINS,
grouping and others.
2) CURSOR method:
DECLARE curs_name CURSOR FOR SELECT TOP total_rows ....
OPEN curs_name
FETCH RELATIVE num_rows_to_skip ...
CLOSE curs_name
Still viable. Can be used by SP that returns table.
3) SQL:2003 method: SQL Server 2005, IBM DB2 and Oracle implements the
"standard" way, i.e. ROW_NUMBER() window function.
SELECT * FROM (
SELECT
ROW_NUMBER() OVER (ORDER BY orderby_columns ASC) AS rowno,
interesting_columns
FROM interesting_table
) t1
WHERE rowno > num_rows_to_skip
AND rowno <= (num_rows_to_skip+num_of_interesting_rows)
This is very powerful numbering method, just dig Google for more.
> I am considering making a substantial change to pymssql to support
> this behavior, but I don't really want to do it if you are not willing
> to merge the patch in.
...
No need to bother; pymssql doesn't need any change wrt pagination. I'd
propose to focus on virtualizing that element in Django to make use of
abovementioned methods when it works with Microsoft SQL, Oracle or IBM
DB2. It'd improve its portability across more RDBMs.
Russell Keith-Magee
>
> So, I can devote dev time to fix the non-sql server support. I have
> read the code, see all the patch (and be confused for its). I'm not a
> python guru but have 3 years of expertise in develop against Sql
> server.
Volunteers are always welcome.
> So, how proceed? To how I need to talk?
As always, the best option is "Just do it". You don't need official
permission to start work. Code speaks louder than words - if you want
SQL Server support, write it.
This doesn't mean your changes will get applied to the trunk any time
soon. I would place the likelyhood of a patch of this magnitude
getting merged into trunk in the next three weeks at somewhere between
"unlikely" and "not a chance in the world". As an example, the Oracle
patch took almost 6 months to get merged - and I'd consider that to be
a pretty good example of a 'fast' time frame.
However, this doesn't stop you from working on the patch, and using it
in your own projects. You can keep your local version of
Django-with-SQL-Server running happily, and upload updated patches to
the Trac repository as required. When you have demonstrated to the
community that you are able to produce good patches, and you are able
to dedicate the time required to maintain the patch over the long
term, we can look at merging the branch into the trunk.
Yours,
Russ Magee %-)
mamcx
Thanks for the pointers (and sorry for the english!).
I work always in the last version of django, so I think is not a
problem.
I take a look at the proposed pymssql library. So I think the best
option is build a all-new backend taking bits from the old one and see
how well the thing goes...
SmileyChris
Good luck! Report back with your progress, I'd be interested to see
how it turns out for you.