Hi Joe.
"devolving" or performing a "rollback" on an evolution is covered only
slightly at the end of my proposal. Basically the idea would be to
also add "pre_rollback" and "post_rollback" function hooks for the
evolve() function as well. This way, the responsible admin would be
able to
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 think it's
a good system. Obviously there are a lot of things to think about.
But this would be a
I know Jacob was working on this, is it still going ahead as planned?
I don't see a wiki, and I'd like to work on it.
Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
I plan on making a migration solution after Magic-Removal trunks. I
have a partial-solution now, but I don't want to work on it just to
need to redo everything afterwords.
On 2/19/06, Ken Kennedy <[EMAIL PROTECTED]> wrote:
>
> I have to concur with Max here. I know it sounds like a pain to
I wonder if with the new "with syntax", you could do something like:
with 404_on_error:
Articles.objects.filter(name__startswith="Whatever")
That'd be sweet.
On 1/31/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> I think Lukes ideas are probably the way forward.
>
> However, another
I always thought the functionality should be within the object:
Person.objects.filter_or_404(pk=2)
Person.objects.filter(pk=2).or_404()
On 1/31/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> The descriptor-fields implementation is firming up, which is good. Now
> it's time to start changing
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> I attempted something like this first time (I think you mean it would
> return a version with caching *enabled* each time, right?), but removed
> it again. I wasn't sure how it would interact with things like
> _default_manager, and also if you
This is all crazy. You people are crazy.
I figured this out months ago:
http://code.djangoproject.com/ticket/980, we didn't have the concept
of the manager back then, of course, but the basic principles are
there, (query == filter).
If you cache the count, len() and bool() can be called over
Ian went over the RuleDispatch at the ChiPy meeting a few months back.
It's a very interesting technique, certainly. But it's usage is
limited in scope, and I think dangerous in appeal. In this case, I
think it's better to apply it at the application level, rather than in
Django itself.
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Hmm... what about django.template (singular) becoming django.templates
> (plural)? Any strong preferences? I think templates makes more sense.
django.templates suggests a collection of templates. django.template
suggests a library, imo.
What's the status on the idea of an event system for Django?
I ask because I've been thinking of a more comprehensive database
transitioning peice, built as a stand-alone django-app. I'd like it
to be able to see when the model was updated and store info about it.
Regestering for a sort of
I'm not really sure if this is known (is there a ticket?), but I'd bet
that this problem will be cleared up after the magic removal branch
goes trunk.
On 1/5/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Hi,
>
> There is an open bug:
> http://code.djangoproject.com/ticket/930 which talks about
On 12/24/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Sounds good -- I like the RequestContext name. Other thoughts?
UserContext?
On 12/16/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> There are quite a number of other areas this can be applied to as well.
>
Middleware?
Woops, relational, yes.
> The problem is that you have thrown away the possibility of this being
> even vaguely similar to normal objects. Its incredibly confusing.
I don't see that, but then again I came up with the idea so it's
obviously not confusing to me. In my view, it seems that the
On 12/7/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> That is just horrible. Sorry. The point is not to treat python as some
> arbitrary data format that might have some relationship to your objects
> : the point is to define classes that act as normally as possible and
> are stored in a
Here's yet another idea, that creates seperate classes for the Model
(table) and the Entity (row). I think the problem with how we've been
thinking about it is that the two have been the same, and in reality
they are not.
http://django.pastebin.com/452621
Model definition:
+1, Instead of "models" what about "orm"?
Database connection:
+1
API usage: Object creation
+1
API usage: Table-level functions
+0 Instead of fiddling with objects_, just allow them to do what
you plan later on, which is to assign a custom Manager class. This
On 12/6/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> That doesn't seem promote a clean separation of "table-level"
> vs. "row-level" functionality.
What is the table-level functionality other than queries? Why not
have a "get" or "query" member in the model class that does queries?
Sure
On 12/1/05, Brant Harris <[EMAIL PROTECTED]> wrote:
> Alright, I'll get up a ticket as soon as I can.
>
As promised:
http://code.djangoproject.com/ticket/980
It explains not only the system but my reasoning.
I think the arguing about the color of the bikeshed thought is
mis-placed here. I'm not offering feedback, i.e. arguing that the
bikeshed is painted the wrong color, I'm offering an idea, a patch,
real code. But, I obviously didn't present my idea well enough, so I
will present it in wiki form
Jonathan Ellis left a pretty brutal attack about Django's ORM on his
blog today that I picked up from Planet Python, and I got to thinking
about it. I don't quite agree with him on many of his points. But I
did agree that the OR syntax, as it stands, is rather ugly.
So I was trying to think of
> That's correct. The "default" keyword is only used by Python, not on
> the SQL layer.
>
> That said, I don't see any reason not to add it in the CREATE TABLE
> statements where appropriate. Any thoughts?
>
I think it a very good idea, the only problem I forsee is that right
now it is easily
I now have a working solution to ticket #12.
I've added some code to management.py that allows one to run:
> django-admin.py transition
This then compares your current db to your models in that app, and
next to each model creates a "transition file" so if your model was
called "app.py", next
24 matches
Mail list logo
