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 provid
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 g
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 th
On 2/22/06, Maniac <[EMAIL PROTECTED]> wrote:
> The concept of always keeping object in a correct state is indeed very
> nice but makes some practicle cases really harder. So I would vote for
> late validation on save() or explicit validate().
+1 on the idea in general.
I like validate(). I thi
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 migra
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 possi
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 a
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
Although, I think it'd be great to have it as propsed, at some point
the OO of your ORM needs to make consessions to the SQL of your ORM.
Which goes back to my earlier proposal.
That said... Person.objects could be a property that returns the
Manager/Query. In this way you could send a cachele
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 an
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. Rather
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 star
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
>
Hrm, I think you are trying to simplify a less common task while
complicating the more common one. It seems more useful to set up
documentation for this case in "Solving specific problems". The more
simple the default project/app layout is, the better it is for people
just picking up Django, and
It's a simple and old bug.
If you do: mod = MyModel(anything=something)
It'll work as expected. You need at least one keyword argument in there.
So, in your example:
"""mod = MyModel(foo_id=1)
mod.bar_id = 2
mod.save()"""
Works.
On 12/30/05, Wojtek/brandlay.com <[EMAIL PROTECTED]> wrote:
>
> S
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?
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Basically, promote Admin settings to a full inner class, rather than
> nesting it in meta. It would still end up in meta though.
>
> Thoughts?
+1
Just last night I was making a new model, and thinking that this should be done.
However, Wh
+1
On 12/16/05, hugo <[EMAIL PROTECTED]> wrote:
>
> >However, if a person *does* use a database, we still want that
> >connection.close() in a finally.
>
> Adapt my idea of middleware for database transaction handling :-)
>
> Essentially if you have code outside the web app context, you handle
> s
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 obje
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 databas
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
w
So here's my best idea:
# myproject/people/models.py contains this:
from django.core import meta
class Person(meta.Model):
first_name = meta.CharField(maxlength=30)
last_name = meta.CharField(maxlength=30)
objects = meta.Manager() # This is mirrors the default behavior.
# OR, s
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 o
Alright, I'll get up a ticket as soon as I can.
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
Half way through ticket #603
(http://code.djangoproject.com/ticket/603/) Robert brings up a topic
of much interest to me, which is the templates and their compilation.
The templates currently go through a seemingly needless two-step
process: compilation and rendering. It seems like the point wou
Bah just saw the new programmer's template tutorial. Although I still
think it'd be nice if you could just render a dict as well.
core.template.Context
What's the reason for this class? I can't see any point to it other
than as a dictionary wrapper.
It seems better to do:
t.render("answer": 42)
Rather then:
c = Context({"answer": 42)
t.render(c)
Unless there is another reason for it?
Shouldn't it not define a default property if there isn't one? Then
it can hasattr(obj, 'default') to find if it is there or not.
On 9/7/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
>
> On 9/7/05, jws <[EMAIL PROTECTED]> wrote:
> > Why not just NOT_PROVIDED = ''?
>
> Because '' is a very reason
> 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 c
I think it'd be duckey to have a FolderField that would work just like
a ForeignKey except that when you looked at the field in the admin
interface, it looked like a directory structure. So if I had a parent
= FolderField("self") in a model, and looked at the model in the admin
interface I could
Alright, so I'm trying to finish the database_check function in
management.py to generate ALTER TABLE commands. Effectively I'm
steamlining my own solution, but it was decided that the two-step
process I made was too 'messy'. Anyhow I wanted some opinions:
Here's the problem, it is impossible t
On 8/31/05, Brant Harris <[EMAIL PROTECTED]> wrote:
> > Erm. Can you create a NOT NULL Column without a default in an ALTER
> > Statement? I know you can't in MSSQL.
>
> It worked fine for me in MySQL... Not sure, although a change in the
> code would be trivial.
> Erm. Can you create a NOT NULL Column without a default in an ALTER
> Statement? I know you can't in MSSQL.
It worked fine for me in MySQL... Not sure, although a change in the
code would be trivial.
The other point you make is the sort of versioning of the transition
file. I see your point,
Well here's the patch as it stands on my system.
transition.diff
Description: Binary data
lovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/30/05, Brant Harris <[EMAIL PROTECTED]> wrote:
> > I now have a working solution to ticket #12.
>
> Your solution is very intriguing. There's already a "django-admin.py
> updatedb", which is currently comm
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 to
42 matches
Mail list logo
