On 1/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > My mistake -- get_pub_date_list() wasn't the best example. Better
> > examples would be completely custom manager methods, such as
> > create_user() and and make_random_password() in
> > django.contrib.auth.models.UserManager.
>
> Is t
On 1/29/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> But note that
> manipulators are next on the list to be hacked-on (see the "making
> models validation-aware" thread on django-developers), so your work
> may become obsolete in
Status update:
- ForeignKey attributes seem to work now - both ends
- ManyToMany attributes - one end works (the 'related' end)
(I didn't do those - just plugged Adrian's bits in)
I won't be doing anything until Monday evening (GMT) at the earliest, if
anyone else wants to hack on it.
Regards,
Hi,Off late I have found that my models are stable, but I have to keep on adding new ones. It would be good if django-admin.py had support for model level install option. "django-admin.py install myapp.mymodel
"? Also it would be nice if we can have atleast model level sqlreset in case model change
Hi,I am using trunk: 2116, and in the admin view, I am not getting the _javascript_ date and time pickers. Everything else seems to be working fine, is this normal?TIA,-- Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay+91-9867-359-701
OK, I've done some more and committed it now.
If you want to go back, it's fairly easy - I've left the old Manager
class in the file - just remove the new one and change the name on the
old one back again. Almost all the changes so far are in query.py and
manager.py.
I've also updated 3 lots
On 1/29/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I just saw http://code.djangoproject.com/changeset/2146 . Seems to me
> it'd be more efficient to do this in "manage.py validate" rather than
> at run-time.
Ah - I hadn't thought of putting it there. Change is on the way.
Russ Magee %-)
Hi all,
Attached is a first go at QuerySet and a new Manager class. This
obviously breaks quite a lot if you apply it!
It includes changes to the tests in modeltests/basic - I've commented
out a handful that don't pass - I'm not quite sure what the syntax
*ought* to be for them. The rest do
I just saw http://code.djangoproject.com/changeset/2146 . Seems to me
it'd be more efficient to do this in "manage.py validate" rather than
at run-time. I'm always weary of doing relatively expensive validation
at runtime when it can be done in the model validator. Russ, would you
be willing to ch
On 1/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The changeset in question:
> http://code.djangoproject.com/changeset/2103 "magic-removal: Restored
> manipulators to code from trunk, removing the unfinished stuff" makes
> it sound like there someone is working on this area, but the cha
On Saturday 28 January 2006 14:23, Robert Wittams wrote:
> Hm, that does make sense. +1 .
Except this sentence, which I never managed to finish:
> > That would mean that if the manager, for instance, happened to be
> > ordered, you would lose ordering if you did an 'or' query, even
> > between.
Luke Plant wrote:
>>hugo and I talked on IRC about this, probably a couple of months ago
>>now. The best we could come up with for the | case was "undefined" -
>>probably remove the ordering clause completely.
>
>
> That would mean that if the manager, for instance, happened to be
> ordered, y
OK, more holes in the proposal. Everything that used to be kwarg to
Manager().get_list() (or other methods), now has to alter the state of
the QuerySet, otherwise caching won't work. So we have the following
that still need sorting out:
select_related
limit
offset
params
select
where
tables
> hugo and I talked on IRC about this, probably a couple of months ago
> now. The best we could come up with for the | case was "undefined" -
> probably remove the ordering clause completely.
That would mean that if the manager, for instance, happened to be
ordered, you would lose ordering if yo
Luke Plant wrote:
> Some more implementation questions:
>
> Presumably:
>
> Article.objects.order_by(('title',)).order_by(('something_else',))
> ==
> Article.objects.order_by(('something_else',))
>
> so that you can override an ordering (I can't see many use cases for the
> alternative i.e. cu
Some more implementation questions:
Presumably:
Article.objects.order_by(('title',)).order_by(('something_else',))
==
Article.objects.order_by(('something_else',))
so that you can override an ordering (I can't see many use cases for the
alternative i.e. cumulative ordering)
But what about thes
Adrian Holovaty wrote:
> I've implemented the very first bit of descriptor fields -- the bit
> that does poll.choice_set instead of poll.get_choice_list().
>
> http://code.djangoproject.com/changeset/2141
>
> Just before that, I'd added a core_filters attribute to Managers,
> which, if set, is a
On Saturday 28 January 2006 00:34, Adrian Holovaty wrote:
> I've implemented the very first bit of descriptor fields -- the bit
> that does poll.choice_set instead of poll.get_choice_list().
I'm up for doing some work on this, and have some time at the moment,
even if it's just converting all the
Hi all,
I just ran the unit test suite on r2144, and noticed that there are
some unit tests failing as a result of some ChangeManipulator changes
around r2103. This is my first time spelunking in the Manipulator
code, so I'm not entirely sure if the problem is bad code, or a bad
test.
Specificia
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > > An implementation question, though: If foo.objects is a Manager
> > > instance, and accessing foo.objects returns a
20 matches
Mail list logo
