DjangoBot: #django-dev

empty, Alex_Gaynor: I'm trying to make django-pyodbc (http://code.google.com/p/django-pyodbc/) work

cool.

it's based on #5246

but it's totally broken

imvho pyodbc is a better option than adodb because I would like to use it also from unix via unixodbc and freetds

i've since dropped support of pymssql and trying to focus in sing pyodbc. It's supposed to support ms sql 2000 and 2005

yah

cramm: that limit code for 2000 is interesting. But I suppose in a single select that's the only way.

woohoo!

of course, that change means i gotta go rewrite part of the book :(

ehe

Oh, how I love thoughtful and informed commentary.

Hehe, blog posts are fun

I'm looking at #7367, and I'm wondering is this guy is abusing the ORM by trying to have two OneToOneFields to `Place` from `Restaurant`? Or is this a bug, considering if both O2O relations point to different `Place` models?

jbronn: one sec; I'll look

jbronn: yeah, if there's two one-to-one relationships, they're not one-to-one :)

Looks like an intermediary model issue to me

OneToOneField is really just for "is-a" relationships, hence the PK munging. I think this is a case of "this word does not mean what you think it means"

Cool, ok if i close it as invalid then?

Alex_Gaynor: I think it's a subclass of FK(unique=True) not generating a single related descriptor on the related class. If we did that (which is an open ticket elsewhere) then everyone would be pretty happy with FK(unique=True)

jbronn: yes, please do

jacobkm: Sorry wasn't clear, I meant this data could be represented with an intermediary m2m

Alex_Gaynor: sure, you could do it that way, too

The createsuperuser command was added to the django-admin/manage.py page, however I don't think it belongs their, since it isn't a django wide thing, it assumes use of the admin, any opinions?

Alex_Gaynor: 99% of the time you'll be using django.ontrib.auth, so I'm fine with it being part of that page. It should mention that it's part of auth, though (does it?)

I'll check

No it doesn't

I'll make a quick diff

cool

Here's the diff: http://dpaste.com/55502/ do you want me to open a ticket?

jacobkm: I could have a look at #5522 if you need more management commands :)

jezdez: why did *_messages end up in django/core/management/base? They really don't belong there...

I think I put them there in accordance with the copy_helper function, though I have no hard feelings moving them to their own django/core/managment/commands/*.py

jezdez: yeah, they should *definitely* be sub-commands. I might not get around to actually aplying the patch right away since it's sort just rearranging deck chairs, but once I've got some time it's pretty much a no-brainer.

cool, great to hear that. I had some i18n work last week with pinax and a djangodash project which reminded me of the usefulness of this reorganisation :) I'll work on a new patch that moves the worker function to the subcommands and would love to actually include a solution for #7180/#5463

#5463

jezdez: on #5463 the patch is fine; the default just needs to stay ".html" instead of the big list the patch uses right now.

Wait, isn't 7180 a duplicate of 5463?

Yeah, it totally is.

yup

ok, I will include the patch on #5463 in the new patch for #5522

jezdez: no, please try to keep them seperate; merging tickets together is a major pain.

feel free to make one patch depend on the other and mark it as such, but please keep things in their place

ok, no prob.

yeah, don't be like #5361 :)

eeep :)

Is there a test application for newforms-admin that exercises most of the features anywhere?

I want to do some work on newforms-admin packages but I need a relatively complete testing environment