inspectdb, mysql and foreign keys in magic_removal

Hi, is inspectdb meant to correctly recognize foreign keys with a mysql database? (from svn, rev 2501) It doesn't work for me ... if it should work, I guess it's a matter of how the constraint was actually created and I'd dig deeper into this. Michael --~--~-~--~~~

Validation Aware Models and django.forms on steroids

The short version of this is really, forms and manipulators merge and get more powerful, models grow validation. This is an attempt to clarify and add to Adrian's previous proposal. I hope it takes care of people's concerns. Here are some details: Forms and FormFields are intended to be used for

Re: inspectdb, mysql and foreign keys in magic_removal

Michael Radziej schrieb: > is inspectdb meant to correctly recognize foreign keys with a mysql > database? (from svn, rev 2501) It doesn't work for me ... if it should > work, I guess it's a matter of how the constraint was actually created > and I'd dig deeper into this. OK, I found that it is n

Re: Aggregate Functions

> I'm not opposed to the idea of a simple min/max etc API in addition to some > mega-aggregate API. I am completely opposed to this. What I am trying to devise is a non-mega-aggregate function that handles 80% of the cases easily. The sum(), min(), max() etc. convenience functions are _not_ that.

Fixing edit_inline on magic-removal

Hey Djangonauts, I've attached a patch to ticket #1330 that fixes the edit_inline support: The "brokeness" of edit_inline on MR is IMHO the major area that makes the branch unusable to many people. The patch reverts some changes (such as the r

Re: Validation Aware Models and django.forms on steroids

Am 08.03.2006 um 16:20 schrieb Joseph Kocherhans: > The short version of this is really, forms and manipulators merge and > get more powerful, models grow validation. This is an attempt to > clarify and add to Adrian's previous proposal. I hope it takes care of > people's concerns. Here are some d

Re: Validation Aware Models and django.forms on steroids

On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: > > Am 08.03.2006 um 16:20 schrieb Joseph Kocherhans: > > So how is a Form connected to a Model? This is the coolest part I think. Unfortunately I buried it with a bunch of other stuff. The AddForm and ChangeForm would be created automaticall

Re: Fixing edit_inline on magic-removal

On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: > > The patch reverts some changes (such as the removal of core fields) > which were never really completed. While I'm aware that a much > improved version of edit_inline is on the way (using Dojo/AJAX and > all that), I think that the branch s

Re: Fixing edit_inline on magic-removal

Am 08.03.2006 um 21:06 schrieb Tom Tobin: > On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: >> The patch reverts some changes (such as the removal of core fields) >> which were never really completed. While I'm aware that a much >> improved version of edit_inline is on the way (using Dojo/A

Re: Fixing edit_inline on magic-removal

I'd just like to support these comments as well. moving stuff now to M-R is a bitch, but doable... there are a lot of changes there. at the moment it is easier for me to upgrade my stuff to django M-R, compared to switching to pylons or TurboGears.. if you change to much more than it is probably

Re: Fixing edit_inline on magic-removal

Christopher Lenz wrote: > I'm all for a feature-freeze for MR: IMHO the remaining bugs should > be fixed, and the contrib apps (such as comments) updated to the new > API, but *before* there's any more major refactorings. Make another > minor release, and push -- for example -- validation-aware mo

Re: Fixing edit_inline on magic-removal

I am +1 on the idea of a feature freeze and was going to make a seperate post on this idea but read this post first. I think there is a lot of good stuff in MR now, and a move towards getting a stable version 0.92 with these features would be brilliant. Naturalyl I want all the future proposed

Re: Finalizing descriptor implementation

On Tuesday 07 March 2006 14:49, Russell Keith-Magee wrote: > > > 3) What is to become of the _id fields for ForeignKeys? > > > > They need to stay around for efficiency; I'd like not to have to do > > a db hit just to find the id of something I've already got. Often > > in bulk-data-import situa

Re: Finalizing descriptor implementation

On 3/6/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I think that if the foreign key is None (for whatever reason), then > __get__ should return None; otherwise it should expect a valid > reference to exist and raise DoesNotExist. (For template authors, > note that DoesNotExist exceptions ar

Character set support for MySQL et al

Hi! I just submitted a patch for alternate unix_socket for MySQL (ticket#1481) but going through it, I noticed SET NAMES 'utf8' (with quotes see ticket #1482 ;) ), but this might be a problem for people using a MySQL server or database using default Chinese for example or other encodings.