inspectdb, mysql and foreign keys in magic_removal

[Michael Radziej]

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



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Validation Aware Models and django.forms on steroids

[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 details:

Forms and FormFields are intended to be used for web applications
only. Models  do validation, so using forms isn't necessary when
manipulating data directly in python. Also, I think something similar
to this would allow for recursive forms (edit_inline behavior), but I
haven't worked out all the details.

Models would grow a validate method and validate=True is added as an
argument to Model's save methods. Models would not do any type
coercion. (I guess they could, but I think most type coercion should
happen in the form fields, not the model fields.)

I'm ignoring a bunch of metaclass magic that needs to go on here, but
I hope the intentions are clear. Bring on the pseudocode...


class Form(object):
def __init__(self, request, prefix=''):
self.request = request
# prefix corresponds to a prefix to http variable names. The prefix
# should be used to strip off the first part of the var names.
# Hopefully this will allow for recursively defined forms... in other
# words, edit_inline is available outside of the admin system.
self.prefix = prefix
# this would actually be more complicated... use prefix to get a dict
# of strings for the form fields to coerce.
self.data = request.POST.copy()

def _get_model_obj(self):
"""
return the cached model object, or init/cache/return one.
"""

model = property(_get_model_obj)

def set_defaults(self):
"""
Call get_default() (hopefully passing in self.request) on each
FormField, and set the appropriate attributes on self.model.
"""

def validate(self):
"""
Basically just return self.model.validate(). Call validate for child
forms as well.
"""

def save(self, validate=True):
"""
Basically just call self.model.save(validate=validate) Call save for
child forms as well.
"""

def html(self):
"""
This is really just convenience for people who are too lazy to write
real templates. Returns a very generic form redered as html. It
should probably have enough css hooks to make it workable though. It
is meant to be called in a template like {{ form.html }}
"""

class ArticleAddForm(Form):
# author will not be editable or displayed
exclude_fields = ('author',)
extend_fields = (
formfields.EmailField(field_name="from", is_required=True),
)

class ArticleChangeForm(Form):
# author will be displayed, but not editable
readonly_fields = ('author',)

class Article(models.Models):
name = models.CharField(maxlength=100)
body = models.TextField()
author = models.AuthorField()

class Meta:
# this gets used in generic create views
add_form = ArticleAddForm

class Admin:
# this gets used in the admin system
change_form = ArticleChangeForm


# Usage:
def myview(request):
add_form = Article.AddForm(request)
errors = add_form.validate()
if not errors:
add_form.save(validate=False)
return HttpResponseRedirect('the_next_page')
ctx = RequestContext({'form': add_form})
return render_to_response('template', ctx)


I hope something like this will come out of Adrian's validation aware
model proposal. This would solve those issues, and add a ton of
flexibility to Django. There are many details that need to be pinned
down, but I think something like this should be workable.

Also, there are things that I've probably overlooked. What are they?

Joseph

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: inspectdb, mysql and foreign keys in magic_removal

[Michael Radziej]

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 not suspected to work at the moment. I'll put 
something together.

Michael

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Aggregate Functions

[Rock]

> 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.

What is that is a function to return multiple aggregates performed on a
single column expression.
If we have that, we have something worthy of putting in MR _right now_
(and a tested patch exists.)

Creating a mega API to handle all the other stuff can certainly wait
for after MR.

Agreed? If not, let's discuss what function would handle 80% of use
cases.


FWIW, Jacob agreed with this approach when I sat beside him as I coded
it up. I consider
him a big player. Meanwhile I am not doing anything else with MR, so I
can take the time to
polish up what I have already coded and then we have something usable
now. It can still be
changed in future releases up to 1.0.

Since I have created one of the largest Django apps (managing over 20
million rows), I am
eager to move to MR as anyone. Some minimal aggregate function support
would be a
huge plus for me and that is why I chose to target that during the
recent Sprint.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Fixing edit_inline on magic-removal

[Christopher Lenz]

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 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 should be merged back into trunk  
before that work is finished, i.e. that that stuff happens on a new  
branch after magic-removal has been merged.

So I hope this patch helps moving the MR branch a bit closer to the  
merge.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Validation Aware Models and django.forms on steroids

[Christopher Lenz]

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 details:
>
> Forms and FormFields are intended to be used for web applications
> only. Models  do validation, so using forms isn't necessary when
> manipulating data directly in python. Also, I think something similar
> to this would allow for recursive forms (edit_inline behavior), but I
> haven't worked out all the details.
>
> Models would grow a validate method and validate=True is added as an
> argument to Model's save methods. Models would not do any type
> coercion. (I guess they could, but I think most type coercion should
> happen in the form fields, not the model fields.)

Agreed. Models should expect the correct Python types, coercion from  
strings/whatever should be in the web layer.

> I'm ignoring a bunch of metaclass magic that needs to go on here, but
> I hope the intentions are clear. Bring on the pseudocode...
>
>
> class Form(object):
> def __init__(self, request, prefix=''):
> self.request = request
> # prefix corresponds to a prefix to http variable names.  
> The prefix
> # should be used to strip off the first part of the var names.
> # Hopefully this will allow for recursively defined  
> forms... in other
> # words, edit_inline is available outside of the admin system.
> self.prefix = prefix
> # this would actually be more complicated... use prefix to  
> get a dict
> # of strings for the form fields to coerce.
> self.data = request.POST.copy()
>
> def _get_model_obj(self):
> """
> return the cached model object, or init/cache/return one.
> """
>
> model = property(_get_model_obj)

So how is a Form connected to a Model?

> def set_defaults(self):
> """
> Call get_default() (hopefully passing in self.request) on each
> FormField, and set the appropriate attributes on self.model.
> """
>
> def validate(self):
> """
> Basically just return self.model.validate(). Call validate  
> for child
> forms as well.
> """
>
> def save(self, validate=True):
> """
> Basically just call self.model.save(validate=validate) Call  
> save for
> child forms as well.
> """
>
> def html(self):
> """
> This is really just convenience for people who are too lazy  
> to write
> real templates. Returns a very generic form redered as  
> html. It
> should probably have enough css hooks to make it workable  
> though. It
> is meant to be called in a template like {{ form.html }}
> """

Maybe this would be better implemented as a template tag?

> class ArticleAddForm(Form):
> # author will not be editable or displayed
> exclude_fields = ('author',)
> extend_fields = (
> formfields.EmailField(field_name="from", is_required=True),
> )
>
> class ArticleChangeForm(Form):
> # author will be displayed, but not editable
> readonly_fields = ('author',)
>
> class Article(models.Models):
> name = models.CharField(maxlength=100)
> body = models.TextField()
> author = models.AuthorField()
>
> class Meta:
> # this gets used in generic create views
> add_form = ArticleAddForm
>
> class Admin:
> # this gets used in the admin system
> change_form = ArticleChangeForm
>
>
> # Usage:
> def myview(request):
> add_form = Article.AddForm(request)
> errors = add_form.validate()
> if not errors:
> add_form.save(validate=False)
> return HttpResponseRedirect('the_next_page')
> ctx = RequestContext({'form': add_form})
> return render_to_response('template', ctx)
>
>
> I hope something like this will come out of Adrian's validation aware
> model proposal. This would solve those issues, and add a ton of
> flexibility to Django. There are many details that need to be pinned
> down, but I think something like this should be workable.
>
> Also, there are things that I've probably overlooked. What are they?

I've probably missed some of the previous discussion, but does all  
this mean that Manipulators would go away completely?

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Validation Aware Models and django.forms on steroids

[Joseph Kocherhans]

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
automatically, just like the default Manager. You can override them in
the same fashion. See
http://code.djangoproject.com/wiki/RemovingTheMagic#YoucanoverridedefaultQuerySets
for how Manager overrides work.

class ArticleChangeForm(Form):
   # author will be displayed, but not editable
   readonly_fields = ('author',)

class Article(models.Models):
   name = models.CharField(maxlength=100)
   body = models.TextField()
   author = models.AuthorField()

   class Meta:
   # this gets used in generic create views. It overrides the
default AddForm.
   add_form = ArticleAddForm

   class Admin:
   # this gets used in the admin system. It overrides the default
ChangeForm.
   change_form = ArticleChangeForm

> > Also, there are things that I've probably overlooked. What are they?
>
> I've probably missed some of the previous discussion, but does all
> this mean that Manipulators would go away completely?

There has been confusion regarding that. Adrian has said that
*automatic* maipulators would go away, which I interpret to mean
"don't use manipulators unless you are doing a custom form, i.e.
changing the manipulator's fields attribute" I may be misinterpreting
though.

What I am proposing here is that manipulators go away entirely. Their
functionality would be replaced by forms.

Joseph

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fixing edit_inline on magic-removal

[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/AJAX and
> all that), I think that the branch should be merged back into trunk
> before that work is finished, i.e. that that stuff happens on a new
> branch after magic-removal has been merged.

While I'm a *huge* advocate of getting MR wrapped up and merged before
it achieves sentience and takes over half the Internet, I'd rather
have any breakage happen here and now rather than post-merge.  I hate
to say it, but a feature-freeze date for MR may be in order: if
something backwards-incompatible hasn't been proposed and agreed upon
before then, it doesn't go (and gets postponed to trunk, perhaps for
post-1.0), and everything post-freeze is pure implementation and
bugfixes.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fixing edit_inline on magic-removal

[Christopher Lenz]

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/AJAX and
>> all that), I think that the branch should be merged back into trunk
>> before that work is finished, i.e. that that stuff happens on a new
>> branch after magic-removal has been merged.
>
> While I'm a *huge* advocate of getting MR wrapped up and merged before
> it achieves sentience and takes over half the Internet, I'd rather
> have any breakage happen here and now rather than post-merge.  I hate
> to say it, but a feature-freeze date for MR may be in order: if
> something backwards-incompatible hasn't been proposed and agreed upon
> before then, it doesn't go (and gets postponed to trunk, perhaps for
> post-1.0), and everything post-freeze is pure implementation and
> bugfixes.

There's the danger of a branch that never merges, because it has too  
many issues to get enough exposure with users (and in turn doesn't  
get enough exposure to enable all the issues to get discovered and  
fixed).

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 models and  
a Dojo-enhanced admin to the next minor pre-1.0 release.

Release often, release early.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fixing edit_inline on magic-removal

[Ian Holsman]

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 easier for people like me to start from
scratch again (and re-evaluate the Django decision)

I'd say get DB layer and the new model syntax fixed and solid, merge
that to the trunk and then work on the validation.

--Ian

On 3/9/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>
> 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/AJAX and
> >> all that), I think that the branch should be merged back into trunk
> >> before that work is finished, i.e. that that stuff happens on a new
> >> branch after magic-removal has been merged.
> >
> > While I'm a *huge* advocate of getting MR wrapped up and merged before
> > it achieves sentience and takes over half the Internet, I'd rather
> > have any breakage happen here and now rather than post-merge.  I hate
> > to say it, but a feature-freeze date for MR may be in order: if
> > something backwards-incompatible hasn't been proposed and agreed upon
> > before then, it doesn't go (and gets postponed to trunk, perhaps for
> > post-1.0), and everything post-freeze is pure implementation and
> > bugfixes.
>
> There's the danger of a branch that never merges, because it has too
> many issues to get enough exposure with users (and in turn doesn't
> get enough exposure to enable all the issues to get discovered and
> fixed).
>
> 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 models and
> a Dojo-enhanced admin to the next minor pre-1.0 release.
>
> Release often, release early.
>
> Cheers,
> Chris
> --
> Christopher Lenz
>cmlenz at gmx.de
>http://www.cmlenz.net/
>
>
>
>


--
[EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fixing edit_inline on magic-removal

[kmh]

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 models and
> a Dojo-enhanced admin to the next minor pre-1.0 release.
>
> Release often, release early.

+2

I have contributed lots of small bug fixes to Django trunk that I have
encountered in my day to day use.  I was simply scratching my itch.
It's hard for anybody to get itchy about bugs they don't encounter in a
non-functional branch.

Until 1.0 I think it is fair to assume that most users are
bleeding-edge types who are willing to put up with a bit of code churn
for the benefit of a nice framework.  Those who aren't can stick with
0.91 which does a fine job.

Kieran


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fixing edit_inline on magic-removal

[ChaosKCW]

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 functionality, but I think MR
have enough meat to count as very usefull improvment over 0.91,
assuming its stable. So I am all for locking down the features and then
polishing it up and getting it stable.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Finalizing descriptor implementation

[Luke Plant]

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 situations you have the need to monkey with
> > ids, and the few db hits the better.
>
> Isn't this covered by descriptor caching? One initial DB hit to get
> the related object, and then all subsequent requests for the id come
> from the cache. Or am I missing something here?

The thing you are missing is that often you only want the id, and you 
don't want to do that initial hit to get the related object at all.

I have a number of use cases where this make a big difference.  For 
example, I have a page list of objects which have related objects.  The 
only thing I want to do with the related objects on that page is 
display a link to them, and I can construct their URLs using just the 
primary key.  So using the id saves me dozens of queries on those 
pages.

So I would be -1 on removing them, unless there was another way of 
getting the id without doing an extra db lookup.

Luke

-- 
"The only skills I have the patience to learn are those that have no 
real application in life." (Calvin and Hobbes)

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Finalizing descriptor implementation

[Max Battcher]

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 are swallowed silently by the
> template engine so you don't have to worry about being bitten by this).

Speaking of which: right now the Template engine isn't swallowing the
Descriptor's DoesNotExist.  I mentioned this and posted a patch:

http://code.djangoproject.com/ticket/1396

Basically, resolve_variable() isn't checking for
silent_variable_failure for attribute/property/descriptor lookups (it
was only checking for that on callable).

--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Character set support for MySQL et al

[Geert Vanderkelen]

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..

Since this is probably going to be needed for all DBMS out there,  
what about a DATABASE_ENCODING setting which will set the character  
set for the connection?

Cheers,

Geert

--
Geert Vanderkelen
http://Kemuri.Org






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---