Re: composite primary key
What you describe is a ManyToManyField in disguise. A thinly veiled disguise. Perhaps you might want to rethink what you actually need. Be carefull not to think too much within the frame of Rational Databases. On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > I need to be able to use models like this: > > class Xlwzl(models.Model): > xl = IntegerField(primary_key=True) > wzl = IntegerField(primary_key=True) > > (they are actually ForeignKeys, but this probably doesn't matter. > This is probably also a good start for ManyToManyFields with an > association object.) > > Now, I heard it's probably not too difficult to add this, and I > already did a little bit meta class hacking with Django. Any joint > efforts or hints on what will need to be done would be greatly > appreciated ;-) > > I immediately see these areas: > > - table creation (SQL) > - automatic manipulators (loading the object in the > ChangeManipulator, pk handling in the AddManipulator) > - comparation > - access by "pk" - probably by a tuple or a dict? > - in_bulk > > Might take a month or so (well, it's not my only task) I'll probably > put up a page in the Django wiki during this. > > Comments? > > 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: +1 on part of #1810 (put parse_dsn() in django.conf)
+0
I have to agree that using DSN style names is a lot easier when you
aren't using a settings.py file. And the argument of only one way to
do it doesn't exactly work here, in my opinion, as it is a rather
widely used standard.
But, on the other hand, I think a parse_dsn function could easily be
supplied by the user.
Ergo, +0
On 5/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I hope that the main django devs will reconsider the merits of using
> DSNs in env to set db connections and accept part of the patch in
> #1810.
>
> I'm -1 on mandating the use of a particular env var to hold the dsn,
> and on the automated slurp into DATABASE_* values, but I think that
> parse_dsn() should be part of the core django distribution.
>
> Uri-style DSNs are in wide enough use that they are a defacto standard.
> And there are very real gains in app portability and security from
> keeping database connection info out of your app code. Not to mention
> that when django grows support for connecting to multiple databases
> (#1142), specifing those connections via DSNs will be a whole lot
> easier (made up example):
>
> DATABASES = {
> 'foo': 'sqlite3://:memory:',
> 'bar': 'postgres://me:[EMAIL PROTECTED]:5219/db'
> ...
> }
>
> As opposed to:
>
> DATABASES = {
> 'foo': { 'DATABASE_ENGINE': 'sqlite3',
>'DATABASE_NAME': ':memory:' },
> 'bar': { 'DATABASE_ENGINE': 'postgres',
> 'DATABASE_NAME': 'db',
> 'DATABASE_USER': 'me',
> 'DATABASE_PASSWORD': 'me',
> 'DATABASE_HOST': 'there',
> 'DATABASE_PORT': 5219
> }
> }
>
> The objections to parse_dsn() seem to boil down to "we already have a
> way to specify connection info" and "DSNs are harder to read", neither
> of which I find convincing. DSNs are just uris, which I would hope
> everyone undertaking to develop a web app can read. And I don't think
> there's any harm in supporting an additional feature that is a standard
> in the rest of the web development world, and adds real value for many
> users (myself included -- I am not about to put my production db
> password into a subversion repository that everyone in the company can
> read).
>
> JP
>
>
> >
>
--~--~-~--~~~---~--~~
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: Schema evolution
Yeah, I always do that. Sorry. On 5/29/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > Brant, > > On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote: > > I've created a proposal for working all of the Schema Evolution tidbits out: > > http://code.djangoproject.com/wiki/SchemaEvolutionProposal > > > > If you get a chance to read and comment, I'd appreciate. > > I noticed in the code that you have auto_add_now, whereas it should be > auto_now_add. At least according to > http://www.djangoproject.com/documentation/model_api/ > > -- > Jeroen Ruigrok van der Werven > > > > --~--~-~--~~~---~--~~ 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: Schema evolution
You got it. I could barely get any feedback on this project anyhow, and I don't have much time right now to focus on it. So, no problem. GL On 5/29/06, Derek Anderson <[EMAIL PROTECTED]> wrote: > > jeroen, brant, ilias, etc: > > schema evolution was an idea suggested and specifically granted for the > SoC project. i don't know who here was involved with ranking the > proposals, but for better or worse mine was accepted. to a certain > extent i expect this to come with a effort not to trivialize my > existence here before i can even get off the ground. > > more to the point: if you have and ideas/recommendations, i'd love to > hear them. if you have questions regarding my abilities/qualifications, > i'll answer those too. but in terms of going forward with your own > implementations, i ask that you put them on hold for just a little > while. if i fail miserably you won't be but a month or two behind > schedule. surely, until then, there are other areas in which you could > contribute without so sharply undercutting my chance for success. > > thank you, > -- derek > > > Jeroen Ruigrok van der Werven wrote: > > Brant, > > > > On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote: > >> I've created a proposal for working all of the Schema Evolution tidbits > >> out: > >> http://code.djangoproject.com/wiki/SchemaEvolutionProposal > >> > >> If you get a chance to read and comment, I'd appreciate. > > > > I noticed in the code that you have auto_add_now, whereas it should be > > auto_now_add. At least according to > > http://www.djangoproject.com/documentation/model_api/ > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Custom Manipulators
Custom manipulators are a pain. Could we think about integrating this cookbook recipie into Django? Or at least start a dialogue about improving this process. http://code.djangoproject.com/wiki/CookBookManipulatorCustomManipulator --~--~-~--~~~---~--~~ 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: Custom Manipulators
Mind if I take a shot at it? On 6/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 6/13/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > > Custom manipulators are a pain. Could we think about integrating this > > cookbook recipie into Django? Or at least start a dialogue about > > improving this process. > > > > http://code.djangoproject.com/wiki/CookBookManipulatorCustomManipulator > > Yeah, refactoring Manipulators is one of the last things I want to > have happen before Django goes 1.0. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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: Manipulators going away?
Is there any discussion on the fate of manipulators? I've done a lot on my own to make it more managable (including making a very cool 'remote manipulator that executes via ajax'), so I'd like to see where this is all going, a plan or what not. Thanks. On 7/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 7/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > I've thought that models will gain validation, but manipulators > > will stay and provide an additional level of validation for stuff > > that e.g. needs custom manipulators. Did I miss something? Can > > someone shed some light onto this? > > Hey Michael, > > You're right -- models will gain validation, and there will be a > helper function/method that returns a data structure that encapsulates > form validation/redisplay (like a Manipulator currently does). That'll > be replacing the current "automatic" manipulators, which I've never > really liked; they were originally intended for use only by the admin > site, not by end users, which explains the problems such as "Why does > file upload not work for the automatic manipulators" and "How can I > use edit inline with the automatic manipulators." > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#django-devel
Being tired of all the craziness and mundane questions of #django, I created another room on freenode: #django-devel, where we can discuss the higher level Django related topics. That's all. --~--~-~--~~~---~--~~ 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: manipulator via ajax
I haven't actually hooked up the javascript validation yet. But it's
a simple task.
Basically I created a class called a "Control" (the name isn't right,
but it's the going title), the Control has two aspects, one is Django
side and one is Javascript side. In the Javascript you declare a
server-side funciton like this:
function Control(element)
{
AjaxControlAspect(this, element); //Makes this object an ajax control.
// "element" binds this control to an HTML element, e.g. a DIV
get_report = remoteFunction(this, "get_report");
// = remoteFunction(this, );
function set_report(what)
{
alert("Report:" + what);
}
}
On the Django side you do:
class Control(AjaxControl):
@exposed
def get_report(request, argument):
return JavascriptResponse("set_report",
"Here is the argument sent: %r" % argument)
That JavascriptResponse actually calls the function "set_report" on
the javascript control.
So if you did, javascript side:
o = Control(some_div);
o.get_report("Hello")
It will give you an alert box saying: Here is the argument sent: 'Hello'
Okay, so you have that bridge, it's basically an RPC mechanism using
JSON. But here's where it gets nifty:
Instead of doing method = remoteFunction(this, "method"), you can also do:
edit_object = remoteManipulator(this, "edit_object");
And then you can call control.edit_object(,
object_id); It will send the contents of that form through to a
control set up like this:
class Control(AjaxControl):
class EditManipulator(Manipulator):
def __init__(self):
self.fields = (
forms.SelectField("weekday", choices=Weekly.WEEKDAYS),
forms.TextField("something"),
)
@form(EditManipulator)
def edit_object(self, form_data, id):
# apply the form_data to the object with pk = id
Anyhow, I'm sure that's terribly confusing. Thusly, I am trying to
simplify it, and work it into something manageable. Then I can
release it. Hopefully I can combine this with a simplified
Manipulator system and we're off.
On 7/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brantley Harris wrote:
> > Is there any discussion on the fate of manipulators? I've done a lot
> > on my own to make it more managable (including making a very cool
> > 'remote manipulator that executes via ajax'), so I'd like to see where
> > this is all going, a plan or what not.
>
> Whoa! I was just thinking about how to write an ajax remote
> manipulator -- how did you do it? Can you specify django validators
> that insert javascript validation to the form's page? Do you have a
> demo or code anywhere for this?
>
> Brendan
>
>
> >
>
--~--~-~--~~~---~--~~
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: #django-devel
You keep #django open too and answer questions in there. Therefore they have no reason to enter #django-devel. On 7/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > On 19-Jul-06, at 1:31 AM, Brantley Harris wrote: > > > > > Being tired of all the craziness and mundane questions of #django, I > > created another room on freenode: #django-devel, where we can discuss > > the higher level Django related topics. > > and how do you guarantee that the crazies and mundane types dont > follow you there? > > -- > > regards > kg > http://lawgon.livejournal.com > http://avsap.org.in > > > > > > --~--~-~--~~~---~--~~ 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: #django-devel
Yeah, and I certainly never meant for #django-devel to be in any way "elite" or a replacement for #django. I've just noticed that in the older days we could talk about more meta-django related things whereas these days it seems quite impossible. "Craziness and mundane questions" wasn't supposed to hold any pejorative. Sorry if I have offended. On 7/19/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-07-19 at 12:08 +0530, Kenneth Gonsalves wrote: > > > > On 19-Jul-06, at 11:46 AM, Brantley Harris wrote: > > > > > You keep #django open too and answer questions in there. Therefore > > > they have no reason to enter #django-devel. > > > > dream on - you can never escape crazies and retards > > Can you two take a step back and think about how bad this thread looks > to others, please? > > It is very hard for an open source project to recover from having a > reputation of being arrogant or insulting towards their user base. > > Thanks, > Malcolm > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New Manipulators and Validation Aware models.
I have built a proposal for a new Manipulator system. Here are some
of the benefits of this new system:
- Custom form views become very simple, and intuitive.
- Validation aware models are harnessed.
- Forms are raised as an exception. This allows the writer to assume
the data is correct the whole way through. However, when there is a
validation exception, it is handled easily.
The proposal can be found here:
http://code.djangoproject.com/wiki/NewManipulators
Here is a sample view using a default CreateManipulator:
def create_poll(request):
try:
m = Poll.CreateManipulator()
poll = m.process(request)
return HttpResponseRedirect('/poll/%d/' % poll.id)
except Form, form:
return render_to_response('poll/create.html', {'form': form})
Feedback and criticism would be greatly appreciated.
--~--~-~--~~~---~--~~
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
Finally! I've been waiting :) On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > How To Be Sexy, Rule 1: The word "manipulator" has really got to go. > > Thoughts/comments/suggestions on Joseph's plan below, and on Brant's > plan in Trac? > I know you want to get rid of the concept of "Manipulator". So two things: 1. I will think very hard of alternate ways of doing this. 2. Currently I think the idea of the "Manipulator" is really quite great. It allows you to define, in a simple way, a Form process. But also, the whole idea of the manipulator means that the "manipulation" of an object is in the "model" space, essentially, and not in the "view" space. Maybe it's a philosophic question, but I see it best defined in the "model" space because then it provides a modular process for views to leverage. Maybe a constructive thing would be to decide what we DON'T like in the current Manipulators system? Personally most of the problems I see, have been sorted out in my proposal. --~--~-~--~~~---~--~~ 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: Re: Validation Aware Models and django.forms on steroids
On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote: > 1. I'm not sure I like the idea of manipulators having a 'process' > method which does everything; it would feel more natural to just try > 'manipulator.save()', have that save if all is well, and catch any > validation errors. The problem is that to make it usefull to the user (read: api-user / developer), you have to put the model save in a try / except block so that if there is a validation error, it can raise the form. Otherwise, the user will have to provide their own try / except block. > 2. Since we're already striving hard to get rid of 'get_absolute_url' > I'm not sure how I feel about introducing a 'get_update_url'. I totally agree. Maybe get_url() and get_edit_url()? I think most objects should have a .url property. And come to think of it, this might be an entry for some sort of routes implimentation, that's not routes (man I hate the routes syntax). > 3. Doing 'manipulator.process(request)' is probably unacceptable, > since there are tons of common use cases where you'll want to fiddle > with the soon-to-be-validated data before you let the manipulator get > involved. I can live with 'new_data' in this case. Yeah, you know I agree. In an earlier rendition I was doing manipulator.process(request.POST), which actually makes a lot more sense to me. But that disallows easy access to the request.user, which makes it harder to make a manipulator that, for instance, automatically updates an author field with the current user. --~--~-~--~~~---~--~~ 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: Re: Re: Validation Aware Models and django.forms on steroids
On 8/24/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > The problem is that to make it usefull to the user (read: api-user /
> > developer), you have to put the model save in a try / except block so
> > that if there is a validation error, it can raise the form.
> > Otherwise, the user will have to provide their own try / except block.
>
> If I'm reading the example on the wiki correctly, you'd already need
> to do this in your view -- the difference is whether the try/except
> wraps around 'manipulator.process' or 'manipulator.save', and though
> it's mainly semantics, I think the latter is preferable.
No, watch for the difference between a ValidationError being raised
and a Form exception being raised. In the ValidationError case, it
must be saved and returned with the other validation errors in the
given step (1. conversion; 2. form validation; 3. model validation),
and then finally a Form exception must be raised.
Check out the ._save() function in the Manipulator. It wraps the user
provided .save(), and catches the ValidationError and raises a Form.
Come to think about it, ValidationError really should be
ValidationErrors, with an s. If at all possible we should get as many
errors out as we can to give to the form-user. That's why I pick out
those three steps above; no later step can go forward, or even check
for errors, before the previous steps are complete.
I did play with:
m = Manipulator(request.POST)
m.save()
That has some merit, I think. But again, the user would have to
provide a try / except block. Something like this:
try:
m = Manipulator(request.POST)
m.save()
except ValidationErrors, errors:
render_to_response('polls/create.html', {'form': m.get_form(errors)})
Not very pretty...
--~--~-~--~~~---~--~~
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
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Brantley Harris wrote: > > Maybe it's a philosophic question, but I see it best > > defined in the "model" space because then it provides a modular > > process for views to leverage. > > Manipulators can (and do) serve not only as model savers. They can > authorize, register, send mail etc. Manipulator is just a very good > pattern for dealing with form POSTs. > > I think that manipulators that save models should still look like other > manipulators and this logic is best suitable to live in a view. If we > relay an entire model manipulation into the model itself then we'll get > two kinds of manipulators: those living in views and those living in models. > I think this is the crux of the problem, honestly. We have to decide if manipulation should be in the "model" space or the "view" space (or is that controller? whatev.). I rather see it in it's own space... MMVC anyone? But you're right, they can certainly be used for other uses, which is why the Manipulator class I made allows you to define whatever save() you might want, including just returning the data so that you can do something with it in the view. --~--~-~--~~~---~--~~ 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
On 8/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Al-rightly then... thoughts? > +1 ValidationErrors with an s, as I've said before: the more errors returned at once, the better. My problem with Joseph's proposal is that I believe it to be too tied to the concept of the Model. Idealy, the Form/Manipulator should not really have anything to do with a Model, except perhaps in the finalization, like in .save(). Also it doesn't end up actually leveraging model-validation. You'd have to define the validation twice, once in the Model, and then once in Field. But leveraging on the Model validation turns out to be rather tricky anyway, even in my proposal. Lo: Let's say I have a dict, named "poll_data" with a data for a new Poll object. And an dict, named "choice_data", which has info for a new choice added in the inline. poll = Poll(**poll_data) errors = poll.save() # We don't get any errors. poll.choice_set.create(**choice_data) errors = choice.save() # But we get some here. So now we return the form with the errors. But the user decides that he can't add his clever poll with a choice that is empty, so he cancels and goes home for the day, expecting that his poll was never created. But alas, it IS created because we did "poll.save()". We could rework it to do poll.validate() instead of saving, but since the Poll then hasn't been created yet, you have to make the Choice without a poll, and then assign it after. Seems like a transaction. --~--~-~--~~~---~--~~ 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
On 8/24/06, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > I gather this proposal means validation will be highly optimised for web > forms and available only on POST? I understand that is the mainline use > case, but I have a preference something that wasn't baked into HTML 'cos > I'll have to hack around it eventually or use something else. > Well according to my original proposal, there would be a Manipulator and a GETManipulator, or a JSONManipulator. It would be easy to make as many as you'd like, just change that process function. > 2: fast fail > > Throwing exceptions means the first error will exit the chain. A lot of > work I do involves gathering as many errors as possible. > No, the Form is only thrown after each one of the three steps (converting data, validating field data, validating model data), if needed. I agree, gather as many errors as possible. > 3: exception based flow > > This will be my inner Java guy no doubt, but using exceptions to manage > mainline execution seems wrong to me. I guess I see validation failure > as not being exceptional behaviour. But as it goes, I think what's there > is about as elegant as you make it with exceptions. Partially related > to 2 because when you walk away from exceptions as a mechanism you are > left with a chaining/pipelining approach, which will support error > collation naturally. > The whole raising a Form thing is just a shocking idea. Like gabor mentioned, it's actually done often in Python. Exceptions are just a different and handy control structure to me; I understand that it's a weird idea, I just don't understand why. Anyhow, ValidationErrors are exceptions now anway, so this, in general, would actually be lessoning the ammount of Exceptions being thrown. --~--~-~--~~~---~--~~ 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
On 8/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > The whole raising a Form thing is just a shocking idea. > > Which, right there, is what I'm opposed to it. Often there's a reason > why things are usually done one way, and I don't want to break from > the standard way of using exceptions. Having a function raise a Form > object as an exception is just strange (to me, at least), and > strangeness is *not* what I'm looking for in form processing. Yeah, and that's fine. Personally, I'm weary of any objection that can cite no other reason but that it is "strange"; many good ideas have been destroyed that way. But whatever, really I'm not pushing the form-exception at all. What I am pushing for is clean and simple api usage for the developer. But what I'm seeing so far is pretty good. If what you say follows. However, many of the details here are still missing. Like how exactly are objects assigned to this Form so that it knows to use the correct validate(), and how to save() the object. And what about Forms that are complex and deal with more than one object, not just one that is inlined? Also, I'm still hazy on how the set_defaults / get_defaults works exactly. --~--~-~--~~~---~--~~ 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: Integrating Django and SQLAlchemy
That's all well and good but there are a few projects going on that would be rendered useless if Django eventually did adopt SQLAlchemy, including the Schema Evolution and the multiple DB branch. Also this puts into question the philosophy of the full-stack, and if you really want to be tied to SQLAlchemy... Both questions that need to be answered later on down the road, I'm sure, but still something to think about. On 8/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 8/30/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > A question then: Once the SQLAlchemy stuff is in and solid, will there > > be any reason *not* to use it? > > We'll decide that when we get there, but I'm inclined to answer your > question with a single word: "Simplicity." Django will continue to > work out of the box, with no dependencies. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > How To Be Sexy, Rule 1: The word "manipulator" has really got to go. > Thinger = "Manipulator" or "Form" # The thing that holds the fields Bah, I try and try, but I can't figure out how to seperate the manipulation process from the Thinger. It really belongs in there. If you can define it in one spot, all of the different apps (including the Admin) can use that same process. This means that the Thinger is an actor on the object, and therefore a "Manipulator". Er, we could change the name to "Negotiator", or "Handler" Perhaps The Thinger doesn't have a home in the MVC paradigm-- It is defining a Form structure (not model structure) and controller code to "manipulate" a model instance. Also, I've realized now that a lot of what is defined in the Django Model should really be placed into the Thinger, as it's not Model specific (like blank=True), but is rather specific to the Admin / Thinger. I guess it's in there for simplicity (DRY and all that), but I wonder if that is correct. --~--~-~--~~~---~--~~ 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: Proposal: Forms and BoundForms
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':
> form.bind(**request.POST)})
>
"send_email_and_redirect()"
I want that function. Surely, this is a basic example, but it hides some of
the other issues that need to be hammered out. How do you access the
data once it's validated? How do validation aware models interact
with this BoundForm? Does the user have to set up a try, except block
when they save an object or does the form know something about the
model that allows it to validate it with the validation aware model?
Finally, how does one set the default data?
> The template would look like this:
>
> ...
Personally I think it should be like this:
{% render-form form %}
That should give you almost exactly what the Admin does. If you want
more control, then you should be able to, but for the most simple
case, this should be possible.
> 1. form.sendername.errors.as_url rather than
> form.sendername.html_error_list. This gives us some flexibility to add
> other error shortcut-display types, like JavaScript or something.
Don't we have template tags for this sort of stuff? I favor a
"to_html" for just about everything in the common case, including
error lists. Otherwise, a filter or template tag should be used, or
the object's class could be subclassed do define other functionality.
(Come to think of it: the template rendering should check for a
"to_html" or ''__html__'' function before it tries str() when it comes
across "{{ object }}")
> Let's change this to be similar to model classes, like so:
>
> class ContactForm(Form):
> sendername = TextField()
> senderemail = EmailField()
> subject = TextField(maxlength=20, blank=True)
> message = TextField()
>
+1
I also think some extra default kwargs should be available:
attributes =
label =
For instance, using the given example:
message = TextField(label='Your message',
attributes={'class':'vRichTextField'})
> One big change, other than the syntax, is that 'is_required' is
> dropped, in favor of 'blank', to match our model syntax. Also, as in
> models, blank=False will be default. Currently in manipulators,
> is_required=False is default.
This is backwards to me. "is_required" is much more descriptive;
"blank" seems to say "this field is blank". I agree that it should
match up with the model, but I posit that the model syntax should
change. New users constantly ask about this in the chat-room; they
don't see a difference between "blank" and "null" in the model syntax.
I prefer "required", which is easier to understand, and is part of
the common web parlance: "required fields are marked in red". I don't
care whether it's default or not, although I would suggest polling
many real-world cases to find the most common option.
>
> Another big change is that each of the Fields in this ContactForm
> would be responsible primarily for *validation* rather than specifying
> the HTML form field. This decouples the concept of validation from the
> HTML form type.
>
I don't understand this, and I think might hold the key to a greater
understanding of your plans, could you explain how validation would
work exactly? Also, I agree with limodou that there should be a
general "validate" function that allows the writer of the Form to
provide some custom validation on the form as a whole. Likewise there
should be a "convert" function that does the same but for conversion
from HTML-POST data to Python data.
> Another thing to note: In the current Manipulator framework, sometimes
> it is convenient to be able to construct self.fields dynamically. We
> should provide a way to do that with the new syntax.
+1
> So that's the proposal -- thoughts/criticisms? I'd like to get this
> out there as soon as possible, because we (or, rather, I) have dawdled
> for quite some time!
Some things occur to me:
The whole BoundForm and Form thing is really crufty. When does the
Form NOT have data associated with it? And when would you really want
to have it validate data but not "bind" that data?
There needs to be a fundemental change in the model syntax as well,
which I'm sure you don't want to hear, but it's true. Half
(hyperbolishly) of the stuff that is in the model syntax is really
there to define the Form. You have this sort of siamease twin, but
I'm not sure if it should be ripped apart or reinforced to support the
whole DRY / in-one-place paradigm.
Defining a Form, should be like defining a Model-Manager, it should be
portable in the way that many applications can utilize it, including
the one the Model was written for AND the Admin. That is why I favor
a "Manipulator" approach which would not only define fields, but also
define what to do with t
Re: Proposal: Forms and BoundForms
On 9/13/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> > > For instance, using the given example:
> > >message = TextField(label='Your message',
> > > attributes={'class':'vRichTextField'})
> > >
> >
> > +1 on this for me. I'd love to be able to do:
> >
> > author = SelectField(attributes={'dojoType': 'Select'})
>
> Agreed on the need, not on the implementation.
>
> [...]
>
> IMHO, a better approach would be to allow rendering extensions to be
> registered on the field itself; e.g.,
>
> author = SelectField(extra_renderers={'dojo':dojo_renderer,
> 'brantley':brantley_renderer})
>
I think this is needlessly complicated and impractical. Remember that
the renderer is the ultimate decider on what to do with the field's
properties, so if the renderer doesn't trifle with 'attributes' or
'label', it doesn't have to. Also, I support a default renderer (for
simplicity), but I don't support multiple renderers for a field class;
I think that is the realm of templatetags-- It is responsible for the
rendering of data after all, not the structure or logic of the data.
--~--~-~--~~~---~--~~
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: FormField.html2python is a static method. Why?
It shouldn't be. You're right. The problem is the FormFields and Manipulators are in a sort of limbo right now. And until we hear from the overworked core devs about it, not much can be done. On 10/20/06, Max Derkachev <[EMAIL PROTECTED]> wrote: > > FormField and its subclasses should define html2python as a static > method, and FormField.convert_post_data calls the method so that it > must be static: > self.__class__.html2python(data) > So, it is impossible to access the field's instance attributes while > converting data. I've just faced a need of field object's state inside > html2python (I use custom FormField subclasses in my custom > manipulators that make use of some state). > > Can anybody explain why html2python is treated this way (I suppose it > was done intentionally)? I don't see any security or performance > reasons for that ... > > > --- > regards, > Max > > > > > --~--~-~--~~~---~--~~ 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: Template engine too tightly tied to settings module.. (specifically TEMPLATE_DIRS)
It's been noted serveral times that the Template engine is too closely tied to the settings, which in turn is too closely tied to the core. No one has offered a well made and clearly defined solution as to how to really seperate it, to the best of my knowledge. This should be discussed. Aside: I think we need some leadership on a few of these key issues. I am not in the position to take on the role On 10/23/06, Le Roux Bodenstein <[EMAIL PROTECTED]> wrote: > > I'm trying to do some form of skinning with Django's templating engine. > Without going into too much detail, my project is kindof a service that > powers multiple sites. Each site can have a skin inside a site-specific > folder. These folders are not parallel to each other. > > for example: > > myapp/webroot/media/domainone.com/myskin/ > myapp/webroot/media/domaintwo.com/otherskin/ > > These folders contain templates. I want to be able to (at runtime) > specify this folder to the template engine. This means adding them all > to TEMPLATE_DIRS is a definite no. I was looking at the documentation > and the code and it doesn't look like this will work. Workarounds like > specifying a long path as the template name > (folder/subfolder/someotherfolder/template.html) will not work, because > these sites should not be able to access each other's templates. > > The main things I am looking for are.. Can I load the template from an > arbitrary folder? Will extends work correctly and load the template > we're inheriting from from that same folder? > > I see that ExtendsNode can take a template_dirs argument, but this > defaults to None and it looks like it never gets passed in. > > find_template_source can also take a dirs argument, but this also > defaults to None and inside filesystem.get_template_sources this > defaults to TEMPLATE_DIRS (from what I can tell this is always the > case) and in app_directories.get_template_sources this is ignored > completely. > > Basically, from what I can tell, the Django template engine is very > (probably too) tightly tied to the settings module and the little bits > that imply otherwise are a misleading. > > Please correct me if I'm wrong about this. Has anyone else thought > about it? Does anyone have ideas on how to fix it or at least work > around it? > > I guess I can try and set TEMPLATE_DIRS at runtime, but that just feels > wrong. I'll have to set it back in a multi-process environment and in a > multi-threaded environment that would probably be a very bad idea. (I'm > just guessing. Please correct me if I'm wrong) > > I don't mind patching the source code, but it would be nice if someone > helps me out and my patches ultimately get accepted, because I would > prefer not to maintain a branch ;) > > > > > --~--~-~--~~~---~--~~ 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: Call for comment: Forms/manipulator replacement, take 1
On 10/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I've attached the first draft implementation of the manipulator ... Yeay! Progress. I'm +1 for progress. I like the direction towards simplification and separation, but I'm not sure if the line is drawn at the correct place. Essentially with the Form-Widget proposal, we've split up the "to_html" (render) and "to_python" into two different classes. Is that something we really want to do? I ask sincerely, are there many use-cases for taking the data in one way but rendering it another? Why not Widgets as the main class, and pass it a conversion function? class ContactForm(Form): subject = TextArea() date = CharField(to_python=convert_date) email = CharField(to_python=convert_regex(email_re)) I still don't like the as_text / as_ul stuff. I think that belongs in template tags. Although I am a bit swayed by Russell's idea of throwing that stuff into a dictionary. form_for_fields / form_for_model +1! Other questions: 1. Default data looks like it will be annoying to put in the view. 2. Validation! I hate validation. Let's just ignore it. If the user enters wrong information, its their fault, right? Why does Django have to deal with it!? 3. We still need a way to render the whole form in a one-to-three-liner. 4. Is model validation completely dropped to the way-side? Maybe we could make a conversion library. Conversion functions could be passed around easily, and the Form Field "DateTime" could point to the exact same converter that the Model Field "DateTime" points to. 5. How would sub-forms work? Lately I've been experimenting with form "trees". I've been working on a very complex form that gathers data via Javascript into one long JSON tree, or collection of dictionaries and lists. Each dictionary describes data that is updated on a model object, and each list describes a set of related objects. I'd like to see this support a like structure. Thanks --~--~-~--~~~---~--~~ 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: Have a look at django.newforms
Awesome. I approve. I'm warming to the whole "Widget" thing.
Although I hate that name, as it's specifically nondescript, I can't
think of another.
Some comments:
I'd like to see auto_id default to "id_%s" rather than False. Why not
just give it as the default?
I love clean_XXX(), and clean()
A great function to add to fields would be "as_row()", it would render
just one row of the form table, as well as the corresponding error if
needed. "as_li()" too. It's very useful when you want to specially
define the layout of a specific field, but you want the rest to be
default. Otherwise if you want to define just one field, then you
have to define them all.
"""Username:"""
For CSS purposes, it would be excellent if the first , containing
the label, had the class "label", and the second, containing the
field, had the class "field". Like:
"""Username:"""
Oh, and the error should be "". And rows of
fields that are required should be "". Again,
CSS guides this.
The actual view-usage still seems a bit bothersome to me, and boilerplate.
What about these for "cleaning" Date-based fields? Or maybe for a
"HumanDateTimeField()".
http://cheeseshop.python.org/pypi/ParseTime/1.0
http://cheeseshop.python.org/pypi/parsedatetime/0.8.0
The second seems more robust, but the first seems more lightweight.
What about sub-forms?
"""
>>> f.clean('Django rocks')
True
"""
Nice.
Overall, great work.
On 11/30/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> The django.newforms library is getting more solid by the day, and I'm
> using it for some personal and work projects. Real-world use has
> helped me find and fix problems with it, and I'm pretty happy with how
> things have turned out.
>
> So, then, I'd encourage everybody to play around with django.newforms
> and post a message if you have any issues or thoughts. There is no
> formal documentation, but the unit tests are *quite extensive* and
> serve as pretty good documentation. The unit tests live in the file
> tests/regressiontests/forms/tests.py.
>
> Probably the last major thing that's still lacking is support for
> creating Forms from model classes. That will be coming soon.
>
> I'd suggest importing the module like this:
>
> from django import newforms as forms
>
> That way you can change it in one place once we move this from
> django.newforms to django.forms. In the interest of making it an easy
> migration, we'll keep the old django.forms around as django.oldforms.
>
> Note that you can also do "from django.newforms import *", if "import
> *" strikes your fancy.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
>
> >
>
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Default representation of a Form
Maybe good practice, but not practical. I'd love to not have to use tables. But practical CSS just isn't there yet. Yes, tables aren't good for general layout, but they still have their uses, and forms are a prime example. On 11/30/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I would say not using tables for layout may count as a good practice > like encouraging clean URLs, proper distinction of GET and POST etc. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Default representation of a Form
Bah. I wish all the browsers supported "display: table-cell", that would take care of all of this nonsense. On 12/1/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Brantley Harris wrote: > > Maybe good practice, but not practical. I'd love to not have to use > > tables. But practical CSS just isn't there yet. > > Many web sites prove otherwise though :-) > > > Yes, tables aren't > > good for general layout, but they still have their uses, and forms are > > a prime example. > > I agree that laying out a form with CSS is not a very clean thing. But > it does give you a way to change the layout with just CSS (like moving > labels to the left or to the top of a field). And with tables you can't > do it in practice. > > Anyway we aren't fighting for the only one available method just for the > default. And since this preference is a controversial subject I think > this is the thing that should just be ruled by core team or we may argue > this to death :-) > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Have a look at django.newforms
One other thing:
-- newforms/forms.py - line 40 --
def __init__(self, data=None, auto_id=False): # TODO: prefix stuff
self.ignore_errors = data is None
Change to:
def __init__(self, data=None, auto_id=False): # TODO: prefix stuff
self.ignore_errors = not bool(data)
That way you can just throw request.POST into the Form.__init__, and
it will work as expected both before and after the form is submitted,
as in:
def login(request)
form = UserRegistration(request.POST)
if not form.is_valid():
return render('login', form=form)
# Form is valid do something here
m, me likey
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Have a look at django.newforms
Another (sorry, I'm pretty sure this is my last today). A label keyword would be great for specifying the label for the field. password2 = CharField(widget=PasswordInput, label="Password (again):") Would render: Password (again): --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
Next on the list should be a Login form. Should be very simple. On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > > What other sorts of things can we make abstractions for, > > > given a Form? > > > > First thing that comes to mind is the same thing you describe but > > without preview. In other words it's what update_object generic view > > does now but it works only on models and often it is desired to work > > this way with arbitrary form. But I'm sure you've already thought about > > it... > > Yes, *definitely*...That one is next on the list. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: proposal: get_or_none QuerySet method
On 12/18/06, Gary Wilson <[EMAIL PROTECTED]> wrote: What do you think about adding a get_or_none QuerySet method? +1 On 12/20/06, Joseph Perla <[EMAIL PROTECTED]> wrote: There should also be an update_or_create() function. +1 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Distributed Applications and Database Data
I've started to impliment my proposal for schema implementation and realized that some database-data might need to be distributed along with updates in the actual application, but there is no mechanism for it. For instance, if an application requires some sort of seed-data, but the requirement it is added in a new version, anyone who updates won't have that data. Is this sort of thing handled in other frameworks? Has there been any talk about this at all? Thanks --~--~-~--~~~---~--~~ 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: Schema evolution
The rollbacks are really only usefull (in my mind) for when you go forward on an app, and it turns out to break something, so you "rollback". I do think it is a bit of a fringe-case, and can be handled by proper database backing up. However, I don't see why we couldn't support it. Plus, I've figured out that we're going to have to keep a record of the models anyway. On 4/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Ok, thanks for clarifying on the comment on rollbacks. > > Still, I think rollbacks shouldn't be included. From the user's > perspecitive there won't be much difference between a rollback and an > evolve. In both cases they can write pre and post (or pre_rollback and > post_rollback) functions. Granted, they'll have to remember what their > models used to look like, but its not really up to us to make backups, > right? If a user really wants to rollback a production app, they can > get an old version of models.py out of their revision control and > evolve with it. If they're prototyping a new app and a change breaks > something, chances are they made a small mistake. Don't rollback - fix > the mistake and evolve forward. > > Its just not clear to me what we're gaining from rollbacks. On the > other hand, keeping track of all the shadows will clutter things up a > lot in the code and in either the filesystem or database (whereever > shadows end up living). > > Joe > > > > > --~--~-~--~~~---~--~~ 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: ATTENTION: magic-removal being merged to trunk TODAY
May I be the first to say: YEAY! On 5/1/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Attention all users of the Django development version (a.k.a. trunk)! > > We are merging the magic-removal branch to trunk this evening, Monday, May 1. > > Do not "svn update" your Django code unless you're ready to convert > your code to magic-removal syntax. > > If you "svn update" by mistake and aren't yet ready for the > magic-removal APIs, you'll be able to "svn switch" back to the last > version of pre-magic-removal Django, which will be tagged in > Subversion. > > Look for an announcement here (on both the django-users and > django-developers mailing lists) after we're done. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Request method in urls.py
There's a line in the django URL Dispatcher documentation that is pretty
weird:
The URLconf doesn’t look at the request method. In other words, all request
> methods – POST, GET, HEAD, etc. – will be routed to the same function for
> the same URL.
Well, why? Most modern web frameworks allow you to specify the method in
the routing configuration, Django seems to be an exception in this respect.
It would be extremely easy to implement, and would lead to vastly better
code across new projects, including a simpler way of writing rest style
interfaces:
url('^objects/$', 'views.create_object', methods=['post', 'put'],
name='create_object'),
url('^objects/$', 'views.get_objects', name='list_objects'),
This has come up many times before and been swatted down for various
reasons. One is that it could be implemented with a one-off dispatcher, as
in:
url('^objects/$', create_or_list(list=get_objects, create=create_object),
name='create_or_list_objects')
But this is overly complex for what should be a simple configuration,
forces one to create the same name for the url, and worse, creates a level
of indirection breaking the abstraction up; or in other words you're trying
to do route configuration, why not do it in the place you're already doing
route configuration?
The other argument is that you can do this with Class Based Views. I don't
believe this is a good argument as one would have to utilize Class Based
Views to get this basic functionality. In fact CBV's, only really solve
two common issues, one is the boilerplate inherit in forms, and the other
method routing. But the proposed solution to method routing is simpler and
better.
I will gladly implement the code required for this, but don't wish to do so
if it's going to be quashed, which is why I bring it up here.
Thanks
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On Sun, Apr 14, 2013 at 4:56 AM, Łukasz Langa wrote:
> On 13 kwi 2013, at 23:48, Brantley Harris wrote:
>
> > It would be extremely easy to implement
>
> Such a statement suggests that the you didn't really think the problem
> through. Few things are "extremely easy to implement", especially in a
> framework with years of legacy projects in the wild.
Which is why I bring up the idea, to hear if anyone has some gotchas or
implementation advice.
>
> > and would lead to vastly better code across new projects, including a
> simpler way of writing rest style interfaces:
> >
> > url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> > url('^objects/$', 'views.get_objects', name='list_objects'),
>
> How would you implement a reverse() variant having this functionality in?
>
Reverse deals only with the url, not the method. Two names "create_object"
and "list_objects" would now point to the same url. Of course the urls
could change at some point and the urls could diverge, but since you've
already separated the two views by name, you don't have to do any more work.
> Does get_objects respond to DELETE as well?
>
Yes, it's the fall through, accepts all methods just as a url does in
Django now.
> If create_objects raises Http404, do we continue traversing the urlconf?
> What about reverse() in that case?
>
No, since Django does not do this with any other urls.
>
> > I will gladly implement the code required for this, but don't wish to do
> so if it's going to be quashed, which is why I bring it up here.
>
> Often you can find tricky edge cases and other obstacles only through an
> implementation effort. Realistically, no-one will agree to merge a
> functionality based only on a vague mailing list post. Working code wins
> arguments, as they say. Alternatively, a careful up-front design document
> (this is what the core Python team does with PEPs).
>
>
I've brought the topic up for discussion, I'm not looking to see it
pre-approved for merging.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant wrote: > One reason for not doing this kind of despatch is that handling for > different HTTP methods often involves a lot of common code. The classic > form workflow would become longer, more complicated and/or less DRY if > it was implemented using two functions instead of one: > > https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view > > So, I would disagree that dispatching on HTTP verb would lead to vastly > better code - it could easily make things worse. > > Form handling seems like the only common place that a view would want to handle different methods coming in, most of the time it makes much more sense to break up the view into one for each HTTP Method. In essence, what we're doing is creating our own mini-dispatch in the view and it's clumsy most of the time and leads to less RESTful layouts. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
Alex, I see http methods as being very basic, a part of the URL itself. In other words, from the level of the web framework it's pointless to talk about the URL as anything but a pair of request method and path. Strangely, I'm not sure I agree with you that intelligent dispatch decisions should happen early on. Rather, I think simple decisions should be made early on. On Monday, April 15, 2013 12:33:42 PM UTC-5, Alex Ogier wrote: > > On Mon, Apr 15, 2013 at 1:22 PM, Donald Stufft > > wrote: > >> >> On Apr 15, 2013, at 1:16 PM, Alex Ogier > >> wrote: >> >> The problem I have with fallthrough-based dispatch is that it encourages >> really expensive performance-killing patterns, where you end up doing a >> linear scan over view functions round-tripping to the database for each one >> to see if the view can handle the request. multiurl is sort of nice because >> it least it's obvious that what it's doing might be expensive, and the >> whole linear scan is collected in one place so if it gets too long it looks >> "wrong" in a Joel Spolsky sense. >> >> >> I don't see how including the method in the resolution scheme equates to >> hitting the database. >> > > Oh sorry, I wasn't totally clear. I am advocating a system where people > are encouraged to make intelligent dispatch decisions like this one early > in the routing framework *instead* of with a try-catch-fallthrough pattern. > Anything that lets you avoid doing extra work through a little up-front > intelligence is a plus in my book, and I think it's a shame that there > aren't really any good hooks to make these kinds of intelligent decisions > in the routing framework. django-multiurl has already done a lot of the > heavy lifting to make multiple URLs for the same regex work in a clean way > outside of core, but it uses this onerous pattern of calling views and > expecting them to fail in a specific way. So I am proposing that it could > easily be made to have all the right hooks to make arbitrary intelligent > routing decisions. > > I think we're on the same side here, except that you want this in core. > > Best, > Alex Ogier > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On Mon, Apr 15, 2013 at 6:32 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> On Tue, Apr 16, 2013 at 6:12 AM, Brantley Harris wrote:
>
>> Alex, I see http methods as being very basic, a part of the URL itself.
>> In other words, from the level of the web framework it's pointless to talk
>> about the URL as anything but a pair of request method and path.
>
>
> I couldn't disagree more on this. URLs and HTTP Methods are completely
> different things. They're even covered by different RFCs. No part of the
> URL spec includes mention of the the HTTP method. The HTTP method is part
> of a protocol for modifying resources identified by a URL.
>
> A URL describes a resource. It describes a "thing" that can have "stuff"
> done to it. That's why HTTP methods like GET/PUT/POST/DELETE are sometimes
> called "verbs" - they're "doing" words, describing what you're going to
> "do" to a resource. GET me the resource. PUT a new resource. DELETE the
> current resource.
>
>
The dispatch process is - and should be - a two phase process:
>
> 1) Decide which resource is affected
> 2) Determine how to handle the request that you've received.
>
> So you want to have different behaviour for different verbs? Fine - then
> you put that at level 2. Yes, there's going to be a repeated pattern here,
> so you'd be well served to have some sort of framework to support this --
> which is what the CBV base class is. If you don't like CBVs, feel free to
> propose something else - but don't try and confuse the task of identifying
> a resource with the task of correctly handling a request for a resource.
>
Yes we can write a dispatcher that doesn't care about the verbs. Wait,
that's what we've already got.
Surely I wasn't being literal when I said that the http methods were a part
of the url, I meant from the standpoint of dispatching a request.
I don't like CBV's. I have proposed something else. It's a simple keyword
argument to url() that solves half of what CBV's are trying to solve
without completely changing the layout of a project to favor needlessly
complicated mini-frameworks of inheritance as opposed to simple composition
with functions.
>
> To bring it back to your original example:
>
> > url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> > url('^objects/$', 'views.get_objects', name='list_objects'),
>
> I completely fail to see the point of having different reverse endpoints
> for these two. At the end of the day, both of them reverse to the same URL
> - '/objects/'. Your proposed usage is presumably something like:
>
> requests.get(reverse('list_objects'))
> requests.post(reverse('create_object'), data)
>
> However, to drive home the point that the verb *isn't* part of the URL,
> the following would also work:
>
> requests.get(reverse('create_objects'))
> requests.post(reverse('list_objects'), data)
>
> That is, you can POST to your "GET" url, and GET from your "POST" URL, and
> you'd *get no error whatsoever*. So… what exactly is the point of having
> different URL names?
>
Views are not resources. The urls.py file maps from the URL/HTTP/REST
world into the world of python functions. When you name your views, you're
doing that, naming your views. You are not naming URL resources. In fact,
the whole point of reverse() is so that you can change your URLs without
having to touch the rest of your code because you have been referring to
the view.
A simple example would be going from this:
> url('^objects/$', 'views.create_object', methods=['post', 'put'],
name='create_object'),
> url('^objects/$', 'views.get_objects', name='list_objects'),
To this, because you need to match an existing url pattern:
> url('^objects/create/$', 'views.create_object', methods=['post', 'put'],
name='create_object'),
> url('^objects/all/$', 'views.get_objects', name='list_objects'),
Now, you can see I don't have to change the rest of my code, I can merely
continue on. This isn't just random simplicity, it uncovers the inherit
nature of these abstractions.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Django Migrations
Having not been content with the state of Django migrations systems, I've created one of my own: http://www.bitbucket.org/DeadWisdom/migratory/ The idea is a database migration system that: * Is simple. * Doesn't make you use sql. This is an orm, we shouldn't have to use sql. * Can be automatic. Predicts the migration script for you so you don't have to think about what has changed. * Works well in a version control system, or even distributed ones. Because damnit. * During the migration process, *allows you to use the state of your previous models as if they were still there*. This is key, and is not done anywhere else, as far as I know. Currently it's tested on mysql, postgresql_psycopg2, and sqlite3. Thanks. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Migrations
Yeah, the tutorial is right here: http://www.bitbucket.org/DeadWisdom/migratory/wiki/Tutorial On Fri, Jan 2, 2009 at 6:57 PM, Yuri Baburov wrote: > > Could you please write some tutorial on your page, how does the > migration process looks like with your app? > > On Sat, Jan 3, 2009 at 2:29 AM, Brantley Harris wrote: >> >> Having not been content with the state of Django migrations systems, >> I've created one of my own: >> >> http://www.bitbucket.org/DeadWisdom/migratory/ >> >> The idea is a database migration system that: >>* Is simple. >>* Doesn't make you use sql. This is an orm, we shouldn't have to use sql. >>* Can be automatic. Predicts the migration script for you so you >> don't have to think about what has changed. >>* Works well in a version control system, or even distributed >> ones. Because damnit. >>* During the migration process, *allows you to use the state of >> your previous models as if they were still there*. This is key, and is >> not done anywhere else, as far as I know. >> >> Currently it's tested on mysql, postgresql_psycopg2, and sqlite3. >> >> Thanks. >> >> > >> > > > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > > > --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Migrations
On Sat, Jan 3, 2009 at 4:43 AM, Russell Keith-Magee wrote: > In the aftermath of DjangoCon [1], Simon Willison, Andrew Godwin and > myself started the django-migrations SIG [2], with the aim of getting > a migrations framework into the Django core that draws from the best > parts of our three respective frameworks (dbmigrations, South and > Django Evolution) > > [1] http://www.youtube.com/watch?v=VSq8m00p1FM > [2] http://code.google.com/p/django-migrations-sig/ > > After some initial activity, there hasn't been much progress, mostly > due to other development priorities in our busy lives (personally, > this means aggregations and some other features for Django v1.1). > However, I have high hopes that we can get discussions going to > deliver something in the v1.2/1.3 timeframe. Ah, I wasn't sure that this was active, cool. > > You clearly have some good ideas (and more importantly, some working > code implementing those ideas) - I would encourage you to get involved > with the SIG. > > Some quick notes regarding what I have seen so far: > > Firstly, your suggestion that people symlink into django.contrib is > _really_ bad practice. There shouldn't be any need for your code to > reside in django.contrib, and I'd like to discourage this as a > practice before it takes hold as a defacto standard. > > If there is some technical reason why the django.contrib namespace is > required, then raise that issue on the developers list and we can see > what we can do to break that dependency. I can't think of anything > that would cause such a dependency, but it's usually the things you > don't consider that turn out to be problems :-) Ah yes, this is definitely a problem. See, I had to be able to import based on a string (database backend), and I was having problems doing so without an absolute import. I defaulted to this, and didn't think much of it. I'll get on this. > >> The idea is a database migration system that: >>* Doesn't make you use sql. This is an orm, we shouldn't have to use sql. > > I would agree that using SQL shouldn't be required, but the consensus > of all the discussions that have taken place around 'the one true > schema evolution framework' is that a raw SQL mode should be possible. > This is for at least two reasons: > > 1) Satisfying DB Admins that want to manually audit any schema change. > The bigger the company, the more likely a migration strategy will be > required, and the more likely that DB admins will want to check > everything you do. > > 2) Performance on very large databases. "for obj in > Model.objects.all(): change(obj); obj.save()" is very Pythonic and > very easy to read, but will not perform very well on large databases. > Having an easy way to drop to raw SQL is essential for these cases. > Yes, my solution to that, although undocumented I realize, is to allow migrations to also be completely sql. So they would live right next to regular migrations, but have a .sql on them. I was also going to make an option to ./mananage.py migrate that is --sql, so it would build the migration for you just the same, but as sql. >>* During the migration process, *allows you to use the state of >> your previous models as if they were still there*. This is key, and is >> not done anywhere else, as far as I know. > > This is very cool, and I like the way that this aspect is implemented > (the stored snapshot files). I had considered solving this problem > using some metamodel magic, but your approach is a lot more elegant. > >> Currently it's tested on mysql, postgresql_psycopg2, and sqlite3. > > Tested in what sense? > - I've run it on my test project and it works? > - I've got a test suite and I've run it for each backend? > - I've got comprehensive test cases which pass for all backends? > > I have two reasons for asking: > > 1) Your test suite seems very small - especially considering the > multitude of edge cases that need to be considered. The breadth of > testing is one way to get indication of how robust the project is. > Tested as in I've got a test suite and I've run it for each backend, BUT, my test suite is not very large yet, and is missing a lot of edge cases, which is what I'm primarily working on right now. > 2) Ticket #7835 describes a feature that should hopefully make testing > schema migration easier - I'd be interested in any feedback you might > have on this ticket, and what features you would need to make testing > Migratory easier. I'll get on that. > > Best of luck with Migratory - this isn't a trivial task, and what you > have shown so far is quite impressive. > Thanks Russ! --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://group
Re: Django Migrations
On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee wrote: > > On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris wrote: >> Ah yes, this is definitely a problem. See, I had to be able to import >> based on a string (database backend), and I was having problems doing >> so without an absolute import. I defaulted to this, and didn't think >> much of it. I'll get on this. > > It doesn't sound like this should be as big a problem as you describe. > Also, keep in mind that database backends are allowed to live outside > django.db.backends - this is how we support external development of > backends. The backend import code from Evolution and from Django > itself should give you a few pointers on how to do this in a location > independent fashion. > It's not a big problem, I'll figure it out. I took the easy way out, and will be punished :) >>> 2) Performance on very large databases. "for obj in >>> Model.objects.all(): change(obj); obj.save()" is very Pythonic and >>> very easy to read, but will not perform very well on large databases. >>> Having an easy way to drop to raw SQL is essential for these cases. >> >> Yes, my solution to that, although undocumented I realize, is to allow >> migrations to also be completely sql. So they would live right next >> to regular migrations, but have a .sql on them. I was also going to >> make an option to ./mananage.py migrate that is --sql, so it would >> build the migration for you just the same, but as sql. > > The 'put the sql in a file' option is the same thing that Evolution > does. Better still would be to be able to 'compile' a python migration > into SQL - this would keep all the auditing DB admins happy - but I > acknowledge that this is a pretty hard ask. Not so hard, there is actually an undocumented command "python manage.py migratesql" that will pop out the sql that the next migration would do. It's not documented so far because if you use it on an edited migration that has custom api commands, they will still run when popping out the sql, which is a problem. Theoretically if I could put it into an uncommitted transaction, everything would work out, but I'm not sure if that works for each backend? So I have to figure that one out. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New Python ORM
This really isn't meant to compete with Django, more with SQLAlchemy. So far it seems like it's main competing feature is handling multiple-databases easily and joining across them. Damien Gassart saw these posts on digg, made by zzzeek and niemeyer, the SQLAlchemy and Storm lead developers, respectively: http://programming.reddit.com/info/24oo3/comments On 7/10/07, David Cramer <[EMAIL PROTECTED]> wrote: > > Not sure if you guys have seen this, but maybe Django can take a bit > from what it does well. > > https://storm.canonical.com/Tutorial > > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: schema evolution [testers wanted]
Russell is being to harsh, I say great work. But I don't think he's necessarily incorrect. Basically, the trouble is that your solution doesn't really solve the bigger problems. Your philosophy seems to be, "Those problems are spiky edge cases", but I think the hope was they would be solved as well, or at least put on track for a solution later on. Surely you are correct in the assertion that v1 => v2 => v3 is structurally equivalent to v1 => v3. But the data can be different, by your own concession, especially if v1 => v2 has some data processing involved. For instance, if a user wanted to take a field or group of fields from a Model and place them into a separate, related Model. Correct me if I'm wrong, but I don't even think your solution supports any sort of data processing like this. You would have to manually save the data, migrate, and then import the altered data into the new schema, which all but precludes a distributed solution. If we go back to Jacob's Schema Evolution page (http://code.djangoproject.com/wiki/SchemaEvolution) you can see that he identifies 3 different tactics, but really there are just two with the third being the combination of them, introspection, and applied migration code. Your solution seems to be square in the introspection camp. But the "applied migration code" side of it is severely lacking, and that's exactly what everyone wants to see. As for the "aka" bit, I also am weary of putting even more meta-data into the model. But the practicality of it is admirable, and I'm impressed by the discovery that it's the only thing you need for proper inspection. And finally I will say that if you just had a plan of action for the migration code bit, then there probably wouldn't be much resistance. I think Django severely needs this introspection part as soon as possible (I've been saying that since its release). It would be especially helpful for development, where the introspection-only works fine, and where it would be used the most. ps. Did you ever see my long-ago proposal? (http://code.djangoproject.com/wiki/SchemaEvolutionProposal) pps. Russell, you can't be '_strong_ -' , what's next '-2'? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: schema evolution [testers wanted]
On 8/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> My goals:
> * Keep the model file as a canonical representation of what the tables
> should look like right now.
> * Keep each migration as an atomic unit.
> * Provide an entry point for raw SQL migrations
> * Provide some validation that the evolutions that are defined are
> sufficient before they are applied, or at least some validation that
> post-evolution, the database is correct.
> * Provide a way to implement the simple cases now, but make the
> expansion path for the future obvious.
> * Provide a clean interface against which to test.
I like all of these requirements. Here's some more I'd like to see:
* Identify a primary use-case, and make it dead simple for that case.
And simple for newbs.
* Provide, not only raw SQL migration entry, but also django ORM
migration entry.
* Add no extra configuation to the models.py.
I propose that the primary use-case should be considered
in-development migrations. At least personally, I find myself
constantly evolving my models.py during development. In this case, I
barely ever care about past evolutions, and introspection works 95% of
the time. I like the '--hint --evolve' idea a lot. However, I think
the standard suggestion should be './manage.py syncdb --hint', which
would generate the evolution and then list a summary of changes, and
then './manage.py syncdb --evolve' would finally enact them. This way
the user must see that summary and mistakes will be avoided. Also
"hint" seems like the wrong word. "suggest", "guide", "auto",
"build"? Hrm, none very good. I can't seem think of a better word;
so I'll ponder that a while...
Part of the allure of my proposal, to me anyway, is the idea that you
can define presync and postsync functions that share the same module
namespace. And each takes a "models" argument. The idea being that
you can use the previous ORM models.py in the presync, and then in the
postsync use the new ORM and the previously generated globals to
change up your data. Meanwhile you could also use the "cursor"
argument to run custom own sql commands. Although I also like the
idea of being able to have a simple sql file.
I don't like the bit about the Meta section. That adds configuration
to the models.py, even if it's not in the Model, proper, it's not that
far off from 'aka', in my view. And, although I like being able to
label snapshots of the schema, I don't like it being the primary
listing device. Each snapshot should work like an SVN version, in my
opinion, that way you can easily see the order without the need of the
Meta section. Perhaps evolution files could be listed thusly: "%s -
%s.py" % (version, label). Also it would be cool if the admin had a
special view for the evolutions of a model.
Nitpickery:
> mutations = [
>AddColumn('Author', 'dateofbirth', models.DateField, initial_value=None),
>DeleteColumn('Author', 'age')
> ]
>
> Initially, the evolution.mutation package will only include some
> simple transforms (Add, Delete, Rename, etc). However, the built in
> set can be easily expanded later on...
Since you have the signature of the past and present schemas, all you
really need to do is specify which tables are added, dropped, and
renamed. Take this structure as an alternative:
evolve( version = 2, drop = ['Author.age'], create = ['Author.dateofbirth'] )
The order of applied transformations shouldn't matter at this point if
you lock your data at the beginning and the end. This is acceptable
because it is easier, and just as robust, to define presync and
postsync functions that share a namespace, rather than to allow
arbitrary functions at any point in your transformation sequence.
And testing in this case is simpler, I'd imagine as you don't have to
define all sorts of test for all sorts of mutations.
> ... So, if pre_christmas_2007.py exists,
> ./manage.py syncdb --sqlhint will generate pre_christmas_2007.sql ...
What about "./manage.py syncdb --sqlevolve"? that fits the ./manage.py
patterns a bit more it seems to me.
Generally, I really like the whole idea, and I wish it was made, so
start doing that.
- Brantley Harris
re: re: pps
> > pps. Russell, you can't be '_strong_ -' , what's next '-2'?
>
> Of course. And then, -3. :-)
You crazy fool. You have no idea what you've unleased upon the world!
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: schema evolution (new and improved)
Er, could you re-factoritize your system into a stand-alone app? Then
it could be added by anyone. That seems like win/win to me.
On 8/9/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
>
> > I thought you were proposing moving away form ordered sequences? Besides:
>
> i am moving towards graphs of schema revisions. but while lines are
> always graphs (and graphs can have order), only the simplest graph can
> be represented as a line. and graph paths are always represented as
> pairs of nodes. there is no way of representing a directed graph
> without specifying the start node and end node of each path:
> http://en.wikipedia.org/wiki/Directed_graph#Directed_graph
> the post validation is just free icing.
>
> > migrations = {
> >'f1': stuff1,
> >'f2': stuff2,
> >'f3: stuff3,
> > }
>
> ie, this^^^ will never support anything but linear, one-way migrations.
>
> which brings us to the greater point. no graph implementation can
> guarantee you can't have multiple paths. that's up to the developer if
> it's a constraint s/he wishes to impose. and multiple paths means you
> can't have guaranteed data equivalence, as you pointed out. (even
> though you can still have data validity, and schema consistency, which i
> argue is good enough) but multiple paths is a feature, not a bug, of my
> design. i'm not going to "fix" my implementation by removing support
> for it.
>
> yet you can easily still create single-path migrations. just define
> your graph that way.
>
>
> but on a larger "forest for the tree's" note russ, i'm hearing that:
> 1) no schema migration that supports multiple paths will ever be allowed
> into django-proper. (not atomic, as you put it, even though i think
> that's not what atomic means)
> 2) no introspection that works using my inadequate metadata syntax (or
> any syntax similar to it, inside or outside models.py) will ever be
> allowed in.
>
> which means you're looking for something designed substantially
> different from what i originally proposed last summer, what i've
> developed, and what i have any interest in developing. should i go back
> to just maintaining this for my own personal development use? can i
> recommend dbmigration, which seems much more up your alley design-wise?
>
> or does anyone have an interest in continued public development of
> automated introspection + migration w/ multi-path support? (i promise
> FK/M2M introspection is coming soon if there's a yes vote out
> therebut it's mysql only right now and i won't bother finishing
> postgres support unless i'm releasing publicly)
>
> derek
>
> p.s. not taking anything personal here, before anyone gets worried
> about that again...just i think we might have irreconcilable differences
> on the basic design elements, and with your "strong -3" on design i'm
> not holding much hope that i'm doing more than pissing in the wind. :)
>
>
> >
>
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: schema evolution [testers wanted]
On 8/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > * Every time I have written an API with a pre and post phase, I have > ended up needing a post-pre and pre-post, and post-post, and pre-pre, > and really-no-I-mean-it-pre Well since the user defines the pre and post phases, he can append or prepend code to either function, these aren't supposed to be stock functions, so a post-post-sync is really just something appended to the post-sync function. > * It doesn't allow for changes that must be performed in sequence - > first_name and last_name must be merged into name _before_ the search > vector field is added and populated. I just don't see why changes, within a unit-migration, need to be made in any sort of ordered sequence, and your example doesn't really change my mind. Can you suggest another example? I'm all ears on this. It seems to me that everything productive can be done by offering pre and post functions, and having to write my own class to do something so simple as move some data seems way more complex than needed. For completeness: this can be done easily with a pre_sync that gathers the "first_name" and "last_name" fields, and then a post_sync that populates the "full_name" field, and populates/updates the search vector field. > Now - I fully admit that there is some finessing to do here, > especially with regards to the capture of SQL generated by the > PythonMutation class. I wonder if the Django ORM could enter a sort of "theoretical" mode that would just return SQL output. > > The order of applied transformations shouldn't matter at this point if > > you lock your data at the beginning and the end. This is acceptable > > because it is easier, and just as robust, to define presync and > > postsync functions that share a namespace, rather than to allow > > arbitrary functions at any point in your transformation sequence. > > I don't believe this is true. Even if your data is locked, there can > still be legitimate reasons for performing operations in sequence. I > gave a simple example previously; the more complex the changes, the > more likely that Again, provide zamples or I will destroy Django. Django exclaims, "Do what he says! He's crazy!" --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django Instead of Rails
When the hell did "pragmatic" become a buzz-word? Oh god, I must be behind the times, that's so ilpragmatic of me. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Taming management.py, the 1730-line behemoth
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Let any (installed) app provide its own manage.py actions in a similar > way -- something like: +1. As I was reading Adrian's post, I was thinking the very same thing. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Attention Oracle Developers
Please review ticket #5461, and the given patch. It refactors the creation and introspection modules of all the backends. I am not able to test on Oracle, so I need someone's help testing it. Thanks. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
