Brant Harris wrote:
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 defau
Can somebody with checkin privs do this? I think the info I posted
earlier will work (followed by a commit, of course):
at top level of a clean checkout:
svn propset snv:eol-style native -R .
cd contrib/admin/media/img/admin
svn propdel svn:eol-style -R .
cd -
cd conf/locale
svn propdel svn:eol-s
> The reason I thought this should go in the branch is that I'm not
> completely satisfied with it, but also I'm kind of 'stuck' with some
> bits of it (not really hard, just keep putting them off - there is some
> duplicated code to do with OneToOne and ForeignKey, some 2.4 isms, and
> that delet
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
Brant Harris wrote:
> 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
Hey folks --
Want to get paid to write Django apps? You know you do...
Well, we're hiring a Django developer, and I obviously want to hire
someone out of the community if at all possible. Full details are at
http://www.jacobian.org/2005/dec/07/job/; drop me an email if you're
interested
On 12/7/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts?
Models: +1, hooray for properties.
DB connections: +1
Object creation/model import: +1
Table-level functions: -0, there may be good underlying reasons for
it, but it strikes me as needless cluttering of the syntax.
Overriding:
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
Brant Harris wrote:
> 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
>
That
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
>>If we could open a branch up to do this kind of stuff soonish, I would
>>like to commit my 'mutually referential models' stuff to it first, as
>>this will be touching a lot of the same code - this basically moves a
>>lot of special-casing for fields out of meta/__init__.py into individual
>>fiel
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
On 12/7/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Also I would prefer an explicit complaint about something called
> 'objects' from the validator rather than renaming it.
That's a good idea. I've updated the wiki page.
> If we could open a branch up to do this kind of stuff soonish, I woul
Robert Wittams wrote:
Oh, and I think that the overriding save and delete is good, but we will
still need an event system in the end
Also I would prefer an explicit complaint about something called
'objects' from the validator rather than renaming it.
If we could open a branch up to do thi
OK, I've added that "Welcome to Django" page. It's displayed ifDEBUG=True and the URLconf is empty. The design is another Wilson
Special.Adrian, I tested here but it seems that you need to configure DATABASE_* before try to runserver.-- Pedro
Adrian Holovaty wrote:
> Thoughts?
>
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> Please comment here rather than on the wiki.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com | chicagocrime.org
>
This does all seem sensible to me so far. Couple of points:
On Dec 7, 2005, at 2:47 AM, Amit Upadhyay wrote:
How about supporting an SQL where clause, as seen in Rails?
FYI, you can already do this with the "where", "tables", and "params"
keywords; you just have to be a bit more explicit about it. See
http://www.djangoproject.com/documentation/db_
On Dec 6, 2005, at 11:00 PM, Adrian Holovaty wrote:
http://code.djangoproject.com/wiki/RemovingTheMagic
* Model definitions (with properties, etc): +1; this is a no-brainer
* Database connections: -0; seems like name-churn to me; unless
there's a big reason to change the name let's just lea
hugo wrote:
[snip]
>
> 1) I'd prefer "manager = PersonManager('name_of_manager_attribute')
> over the "an attribute named objects will magically turn into objects_"
> - the default for the name should be 'objects', but if there already is
> an attribute named that, the validator should barf. And
I like the general take. My first thoughts:
If db provided an appropriate __all__ then this would be more succinct:
from django.db import *
class Toy(Model):
name = CharField(maxlength=30)
colour = CharField(maxlength=30)
class Person(Model):
first_name = CharField(maxlength=30)
On 7 dec 2005, at 10.53, Daniel Ericsson wrote:
I find the use of "objects" as a way of namespace separation a bit
off-putting. Enforcing an invocation-style via stack inspection
would cut down on the line-noise. Not a terribly big deal, just how
I'd try to do it unless there'd be somethin
On 7 dec 2005, at 06.21, Adrian Holovaty wrote:
But my rationale for changing to the magic object approach is: If we
move to class-based lookups (Person.objects.get_list() rather than
people.get_list()), the class will have been imported *anyway*, so
it's not too much of a big deal to have to u
my 2c's
I don't see an explanation in the wiki page on why I should care about
any of this. from what I see i just see myself doing some 'busy' work
rewriting my apps to use this new method.
What does removing the magic let me do which I couldn't do before?
specifically.. I'm looking for the m
hugo wrote:
2) I really, really dislike the
Person.objects.get_list(Person.q.first_name == 'Adrian')
+1
On 12/7/05, Simon Willison <[EMAIL PROTECTED]> wrote:
On 6 Dec 2005, at 21:00, Adrian Holovaty wrote:> Thoughts?>> http://code.djangoproject.com/wiki/RemovingTheMagicI really like almost all of it. My one hang-up is this:
Person.objects.get_list(Person.q.first_name == 'Adrian')I like the Person.obj
Somehow googlegroups ate my comment. Second try.
Overall comment: "removing magic" is a bit irritating if you actually
just exchange it for other magic (like query objects) ;-)
>Please comment here rather than on the wiki.
Two dislikes:
1) I'd prefer "manager = PersonManager('name_of_manager_a
Adrian Holovaty wrote:
http://code.djangoproject.com/wiki/RemovingTheMagic
Please comment here rather than on the wiki.
My concern is not about removing the magic, but you described a change
to using connection and cursors that I'm concerned about.
Right now Django has some problems with
27 matches
Mail list logo
