ANN: Alpha release of new MS SQL Server backend
mamcx
a clean direction from the ado_mssql confusion of tickets.
Is at http://code.djangoproject.com/ticket/5062.
I run my own test and the standar django ones (however I'm very
intrigated by the fact I found only 2 problems here... I simply do
runtest --settings settings as usual).
I hope tomorrow see how hard is emulate the LIMIT thing based in the
code of oracle backend.
Jacob Kaplan-Moss
On 8/2/07, mamcx <mam...@gmail.com> wrote:
> I submit a ticket with patchs for enable a new backend, so we can have
> a clean direction from the ado_mssql confusion of tickets.
Lookin' good -- keep up the good work!
I know you're very much in the early stages of this, so I'll hold off
on any serious feedback until you've progressed a bit further.
However, I did want to suggest that you submit your pymssql patches to
the upstream maintainer. We can't accept code into Django that'll
depend on patched versions of upstream code, so you'll need to get the
pymssql folks to accept your bugfixes (or figure out how to work
around the bugs).
Jacob
mamcx
I'm waitting to see if the actual pathc for pymssql is enough or still
need more work for do a single submit...
pk11
we are also using django with pymssql/mssql, in addition to your work,
we changed:
- django's admin log model object_id's type is changed from text to
integer (is there a reason why object_id is declared as textfield?)
- pymssql is changed to allow unicode strings
- simulate limit with TOP
- mysql throws an error because it can handle only 23:59:59.99 but
not 23:59:59.999999, please see: django/db/models/fields/__init__.py
at 222 line
let me know if you guys want to work together.
cheers,
peter
mamcx
I finish today a implementation of LIMIT so I'm interested in how you
solve it.
Jeremy Dunck
> - django's admin log model object_id's type is changed from text to
> integer (is there a reason why object_id is declared as textfield?)
object_id is whatever the arbitrary model's PK is, and you can't
assume it's an integer in the general case. The model's PK is
serialized to text.
> - mysql throws an error because it can handle only 23:59:59.99 but
> not 23:59:59.999999, please see: django/db/models/fields/__init__.py
> at 222 line
mysql or mssql?
pk11
I meant mssql, sorry.
the issue with object_id is that mssql can not insert an integer PK
into a TEXT field.
so how should it be handled then if the field type can not be changed?
peter
On Aug 3, 9:02 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote:
pk11
the generic idea is to attach LIMIT as if the backend supported it and
at query execution time replace it with TOP.
OFFSET can be handled by nested queries but i did not have enough time
to finish that.
(i.e.
http://groups.google.com/group/django-developers/browse_thread/thread/7ad0d5f5e3a76c40/89a6eb0e2ad64f6d?lnk=gst&q=mssql&rnum=2&hl=en#89a6eb0e2ad64f6d)
cheers, peter
Jeremy Dunck
> into a TEXT field.
>
I guess I'm confused. Admin LogEntryManager forces object_id to a
string before saving. Do you see somewhere that's directly filling
LogEntry.object_id with an integer?
pk11
Jeremy,
I tested the admin + pymssql backend again without my modification
(i.e. changing object_id's type), and now seems to be working just
fine. do not really know what was causing the issue before though.
anyway, thanks for the information.
Peter
On Aug 4, 9:21 am, "Jeremy Dunck" <jdu...@gmail.com> wrote:
pk11
in django/db/models/fields
222 # mssql can not handle more than two 99-s
223 return ['%s-01-01 00:00:00' % value, '%s-12-31
23:59:59.99' % value]
On Aug 3, 6:34 pm, mamcx <mamc...@gmail.com> wrote:
mamcx
I test it and tommorrow in the next 2 days do another release...