Re: Ticket 8764 (Mixing args and **kwargs in reverse() function)
On Jan 7, 3:43 am, Malcolm Tredinnick
wrote:
> On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote:
> > There are many instances where, in a complicated implementation of
> > views, one might want to have a combination of required args and
> > optional kwargs, and the inability to mix them introduces all sorts of
> > complexities to the logic of the views that shouldn't have to be dealt
> > with.
>
> I'll disagree with this. Whilst it's easy when one is faced with a
> particular problem to imagine that it must be a common case, in reality
> there aren't really that many instances where mixing is required (in
> fact, I can't think of *any* where it could be compulsory -- it's purely
> an alternative representation, so rewrites are always possible). There
> are cases where it can be used, as you witness, but it's not *required*.
E.g. Werkzeug Routes takes this further and handles *only* kwargs.
Less code, less complexity, less bugs, no problems whatsoever.
It goes as follows (simplified look at request-resolve-response
cycle):
def __call__(self, environ, start_response):
resolver = self.url_map.bind_to_environ(environ)
view, kwargs = resolver.match()
response = view(request, **kwargs)
return response(environ, start_response)
+1 to current behaviour or dropping supporting positional args tuple
passing altogether to get rid of the complexity.
Kilarny, which argument handling problems you have remain unsolved in
following examples?
>>> def foo(a, b, c=None): # 2 required and 1 optional arg
... pass
...
>>> foo(**{'a' : 1, 'b' : 2})
>>> foo(**{'a' : 1 })
Traceback (most recent call last):
File "", line 1, in
TypeError: foo() takes at least 2 non-keyword arguments (1 given)
>>> foo(**{'a' : 1, 'd' : 3 })
Traceback (most recent call last):
File "", line 1, in
TypeError: foo() got an unexpected keyword argument 'd'
>>> def foo(a, b, **kwargs): # 2 required and any optional args
... pass
...
>>> foo(**{'a' : 1, 'b' : 1, 'd' : 3 })
>>> foo(**{'a' : 1, 'd' : 3 })
Traceback (most recent call last):
File "", line 1, in
TypeError: foo() takes exactly 2 non-keyword arguments (1 given)
--~--~-~--~~~---~--~~
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: Some tickets that should perhaps get looked at before 1.1
I'd also love to see 8898 committed. It looks to be a fairly straight- forward bug fix, at least to me. http://code.djangoproject.com/ticket/8898 Cheers. Tai. --~--~-~--~~~---~--~~ 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: Some tickets that should perhaps get looked at before 1.1
I'd like to remind everyone that the policy for bugs is to fix them, they don't all need to be listed, because the goal is to fix them all. Alex On Wed, Jan 7, 2009 at 3:47 AM, Tai Lee wrote: > > I'd also love to see 8898 committed. It looks to be a fairly straight- > forward bug fix, at least to me. > > http://code.djangoproject.com/ticket/8898 > > Cheers. > Tai. > > > > -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: #3566 Aggregations: Call for testing
On Wed, Jan 7, 2009 at 7:45 AM, Russell Keith-Magee
wrote:
> On Wed, Jan 7, 2009 at 4:19 AM, Ian Kelly wrote:
>>
>> On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
>>> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
The SQL command not properly ended appears to be the result of an annotate
call followed by a call to aggregate(). I don't have a clue what causes
that as I've used Oracle in my life :) .
>>>
>>> I'll take a look at the queries tomorrow and see if I can straighten them
>>> out.
>>
>> The "ORA-00972: identifier is too long" error is caused by the column
>> alias names not being truncated to an acceptable length
>> ("book__publisher__num_awards__min" in this case). The call to
>> perform the truncation is django.db.backends.util.truncate_name(alias,
>> connection.ops.max_name_length()).
>>
>> The "ORA-00923: FROM keyword not found where expected" is caused by
>> one of the column alias names being an unquoted keyword ("number" in
>> this case). Quoting the column alias names with
>> connection.ops.quote_name(alias) will fix it.
>>
>> The "ORA-00933: SQL command not properly ended" errors are caused by
>> queries of the form "SELECT foo FROM (SELECT bar) AS subquery". The
>> "AS" keyword needs to be removed, because Oracle doesn't accept it for
>> subquery aliases.
I've just pushed some updates to Github that should hopefully fix the
problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
and the decimal/datetime conversion problems). If someone with access
to an Oracle test machine can confirm that this has cleaned up the
errors, I'd be much obliged.
There is some potential for further refactoring here, especially with
regards to the decimal/datetime conversion routines. The Oracle
DatabaseOperations.convert_values() function that I added for
aggregate support is an almost perfect subset of the features in the
Oracle Query.convert_values() function.
Refactoring Query.convert_values() into the backend operations would
remove some code duplication, and would also serve to keep all the
data coercion/typecasting code in a common location rather than
spreading some of it into the Query class. However, there are two
things that prevented me from doing this refactor.
Firstly, Query.convert_values() uses a lot of isinstance() calls on
fields, rather than checking the internal type of the field.
Aggregates use the internal type because aggregates aren't actually
fields, but they do return database types. Ian - can you see a problem
with converting the isinstance(field, DecimalField) calls to
field.get_internal_type() == 'DecimalField' etc?
Secondly, contrib.GIS has a convert_values() function that invokes
super(GeoQuery, self).convert_values() in the case of an Oracle
spatial backend. Justin - is there any particular reason to call the
GeoQuery base class specifically, rather than invoking
self.connection.ops.convert_values()? Is GeoQuery likely to have a
base class other than OracleQuery in the Oracle case?
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://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: making some generic views more generic
Hi Malcolm, Thanks for your input. I can certainly understand your perspective of wanting to keep the maintenance burden for Django to a minimum. Sorry about the formatting. I didn't realize it wouldn't translate so well into the mailing list post. I'm new to the open source world (that's probably obvious). Thanks for pointing me towards dpaste, I'll be sure to use that in the future. On Jan 6, 6:46 pm, Malcolm Tredinnick wrote: > On Tue, 2009-01-06 at 11:01 -0800, Gabe wrote: > > Hello, > > > I really like the generic view feature of Django. It's been a handy > > way to save a lot of work. Lately though, I've been finding myself > > often wanting to display a list of objects filtered by some field. The > > documentation suggests handling this by writing a small view that > > filters the objects and then calling the generic view from within > > that. This works fine of course, but it seems that in a lot of cases > > one can end up writing a large number of small views that all simply > > display a filtered list of objects. I figured it might be helpful to > > abstract this behavior into a couple of additional generic > > views. These will automatically filter based on a keyword captured in > > the URL and a field specified in the urls.py file. I've called these > > new views object_list_field and object_list_foreign_field. > >From the description you've provided here, this sounds like a few lines > > to filter the queryset appropriately and then call an existing generic > view. That's the normal approach when you need more filtering: filter > the queryset and then pass of the existing view, perhaps after also > updating extra_context. Your code seems quite long and has wrapped > fairly horribly in the email, so my eyes were watering a bit too much to > read it all (if you really, really have to provide code of that length, > either an attachment or a link to something like dpaste would be great). > > I don't think this should be added to Django. If it scratches your itch, > then that's ideal. I think you could look at the wrapper approach for > simpler code, but that's entirely up to you for your purposes. However, > since the wrapper approach in conjunction with existing views does solve > this, it's a strong argument against needing to include it in core. > There are a million and one different use-cases that could be abstracted > in various forms. Django shouldn't include functions for all of them, > even if there's more than one user for it, since it would make the > codebase huge and adds stuff we have to maintain forever. We're working > with something that's closer to a library than a framework in many ways > (code is built on top of it, rather than within it) and so people should > be encouraged to build their enhancements externally. > > Please, please don't take this the wrong way. It always looks a bit > horrible when somebody posts a bunch of code and a problem description > (you get bonus points for at least mostly describing the problem you're > trying to solve here -- something that is often missing in proposals > that leap straight to solutions) and then some bozo like me comes along > and says they're not enthused. Remember that (a) it's only my opinion, > although that does carry some weight with some people and (b) I'm > answering from the perspective of "this is django-dev and you're asking > about including it in core", not evaluating whether the idea has any > validity at all in the wild. > > Best wishes, > 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Confusing test case in tests.modeltests.mutually_referential
I'm working on a backend for MS-SQL server 2000 with pretty good success so far, but I'm having trouble understanding one of the test cases in the Django test suite. In tests/modeltests/mutually_referential/models.py, there's a doctests that reads: --- # Create a Parent >>> q = Parent(name='Elizabeth') >>> q.save() # Create some children >>> c = q.child_set.create(name='Charles') >>> e = q.child_set.create(name='Edward') # Set the best child >>> q.bestchild = c >>> q.save() >>> q.delete() --- For reference, the application is generating the following DDL: BEGIN; CREATE TABLE [mutually_referential_parent] ( [id] int IDENTITY (1, 1) NOT NULL PRIMARY KEY, [name] nvarchar(100) NOT NULL, [bestchild_id] int NULL ) ; CREATE TABLE [mutually_referential_child] ( [id] int IDENTITY (1, 1) NOT NULL PRIMARY KEY, [name] nvarchar(100) NOT NULL, [parent_id] int NOT NULL REFERENCES [mutually_referential_parent] ([id]) ) ; ALTER TABLE [mutually_referential_parent] ADD CONSTRAINT [bestchild_id_refs_id_4a696c71] FOREIGN KEY ([bestchild_id]) REFERENCES [mutually_referential_child] ([id]); CREATE INDEX [mutually_referential_parent_bestchild_id] ON [mutually_referential_parent] ([bestchild_id]); CREATE INDEX [mutually_referential_child_parent_id] ON [mutually_referential_child] ([parent_id]); COMMIT; Is the expected behaviour that deleting the parent, the child objects should set their foreign keys to the parent to NULL? The post condition of the test case isn't all that clear to me. vic --~--~-~--~~~---~--~~ 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: Session-based messages (Contrib-05, #4604)
Ramiro Morales schrieb:
> What directions do [the rest of the] core devs think should this
> take?
I am not a core dev, but here is what I think:
- The current user based messages are not usefull for me.
- I use a own version of session based messages which is based
on code of this ticket. But I added an optional loglevel argument.
- Although I use sesion based messages, I want to use a different
aproach in the future, since they produce unneeded UPDATE statements.
HTTP POST, create_message('Changes were saved'), Redirect after Post,
GET, pop_messages() --> SQL UPDATE.
The second request (GET) could be readonly.
Maybe something like this snippet would be good:
http://www.djangosnippets.org/snippets/1064/
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Javascript issue on admin interface with prepopulated_fields
I've noticed that if you have a ModelAdmin with the prepopulated_fields
attribute set to:
prepopulated_fields = {"object_identifier": ("object_type",)}
where the field "object_type" is a dropdown box (that is, has a
choices=CHOICES argument) then the javascript that autofills the
"object_identifier" field does not work properly when you choose an
element with the mouse (what most users do).
To solve this, I modified
./django/contrib/admin/templates/admin/prepopulated_fields_js.html
replacing the event "onkeyup" on line 5 for "onchange".
Do you think this change could be applied to trunk? Do you want me to
submit a ticket and/or patch?
Thanks for your great work and this excellent tool.
Matias.
--~--~-~--~~~---~--~~
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: #3566 Aggregations: Call for testing
On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
wrote:
> I've just pushed some updates to Github that should hopefully fix the
> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
> and the decimal/datetime conversion problems). If someone with access
> to an Oracle test machine can confirm that this has cleaned up the
> errors, I'd be much obliged.
>
The aggregation tests now pass. aggregation_regress has one (minor?)
problem:
Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS ...
FAIL
==
FAIL: Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "d:\u\kmt\django\aggregates.git\django\test\_doctest.py", line 2180,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
regressiontests.aggregation_regress.models.__test__.API_TESTS
File
"D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
line unknown line number, in API_TESTS
--
File
"D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
line ?, in regressiontests.aggregation_regress.models.__test__.API_TESTS
Failed example:
Publisher.objects.annotate(avg_price=Avg('book__price')).aggregate(Max('avg_price'))
Expected:
{'avg_price__max': 75.0...}
Got:
{'avg_price__max': 75}
--
Ran 1 test in 11.757s
FAILED (failures=1)
Destroying test database...
--~--~-~--~~~---~--~~
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: Javascript issue on admin interface with prepopulated_fields
On Wed, Jan 7, 2009 at 9:50 AM, Matias Surdi wrote: > To solve this, I modified > ./django/contrib/admin/templates/admin/prepopulated_fields_js.html > > replacing the event "onkeyup" on line 5 for "onchange". > > Do you think this change could be applied to trunk? Do you want me to > submit a ticket and/or patch? Hi Matias, Sure, go ahead and file a ticket in our ticket system, here: http://code.djangoproject.com/newticket Adrian --~--~-~--~~~---~--~~ 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: #7210 - F() syntax, design feedback required.
I've spent some time looking at this trying to implement expansion of
related fields as Russ and I discussed last night. I have a few questions
about the design choice that was implemented, why didn't you choose to go
with this evaluator class in place of a mechanism more similar to the way
aggregates are implemented. Specifically the issue that has come up is that
whatever goes into the Queries where attribute needs to know the table alias
that it's going to be on, and while this can quite easily be accomplished by
passing it to it at the time evaluate() is called when bump_aliases is
called(on an update query for example) this necessitates the relabeling of
all the aliases, right now there's a hook for this(that aggregates make use
of), but that can't be used since QueryWrapper is being used and opaque
strings of SQL are being passed around. Essentially the question boils down
to why don't we defer creating the SQL until it's actually needed?
Alex
On Mon, Jan 5, 2009 at 5:09 PM, Malcolm Tredinnick wrote:
>
> On Mon, 2009-01-05 at 22:21 +0900, Russell Keith-Magee wrote:
> > Hi all,
> >
> > I have a design issue on ticket #7210 that requires some feedback from
> > the community.
> >
> > For those that haven't been following along, Ticket #7210 is about
> > adding the ability to reference fields during a query. Two quick
> > examples of common use cases:
> >
> > Find all the hotel rooms that have the same number of chairs and beds:
> > >>> HotelRoom.objects.filter(n_chairs=F('n_beds'))
> > => SELECT * from HotelRoom WHERE n_chairs=n_beds;
> >
> > Update the number of occupants in room 319 the room by 1:
> > >>>
> HotelRoom.objects.filter(room=319).update(n_occupants=F('n_occupants') + 1)
> > => UPDATE HotelRoom SET n_occupants=n_occupants+1 WHERE id=319;
> >
> > Nicolas Lara did some work on this ticket in the scope of his
> > Aggregates work, leading off an earlier patch from Sebastian Noack.
> > The ticket was accepted for v1.1 as a must-have. My Github repository
> > contains the work-in-progress [1]; from my testing, it appears
> > reasonably solid, although there is still one feature addition
> > pending.
> >
> > However, the test cases don't currently pass for all backends, which
> > leads me to a problem of design and scope. The test suite for F()
> > notation has revealed some interesting inconsistencies with the
> > handling of various operators on the various database backends.
> >
> > Consider integer division. 42/15 returns 2 under SQLite and Postgres.
> > MySQL, however, returns 2.8, which is rounded into 3 if you try to
> > assign the division result to an integer column. (e.g., UPDATE person
> > SET age = 42/15 ...).
> >
> > Postgres doesn't allow modulo arithmetic on floats; MySQL and SQLite do.
> >
> > Bitwise operators (& and |) on floats are also inconsistently handled.
> > SQLite and MySQL are in agreement, but Postgres won't allow bitwise
> > operations on floating point values without explicit casts to integer
> > types.
> >
> > This doesn't even get into the issue of handling dates and strings
> > using overloaded arithmetic operations.
> >
> > I can see several possible ways forward:
> >
> > 1) Expose the underlying operations, warts and all. Provide a minimal
> > test suite that checks that it is possible to do each of the
> > arithmetic operations, but studiously avoid edge cases known to cause
> > problems. This is the ostrich solution, but it also acknowledges that
> > there are differences between backends. Documentation would be updated
> > to note that some operations are not necessarily portable, and users
> > should check local guides for details.
>
> My gut feeling is that this is probably the most pragmatic, in terms of
> functionality.
>
> To my mind, whilst Django supports multiple database backends, it's
> unrealistic (and not even *currently* true) to say it performs
> identically on all backends. Any individual or company is going to be
> running their software primarily on one database backend, not chopping
> and changing, so they'll know (or should, if they're serious) what the
> behaviour is. I strongly suspect Django-using applications are similar
> to software development in general: the bulk of code is written for
> internal purposes than distribution purposes.
>
> Let's not try to disguise differences that were quite possibly one of
> the differentiating features when somebody was making their backend
> decision. "Django wraps the database layer; it doesn't replace it."
>
> > 2) As for (1), but provide a comprehensive test suite that checks the
> > different expected results for each backends.
>
> We might need to introduce some backend-specific tests over time, but we
> can backfill as experience dictates there. I wouldn't let this hold up
> the merge.
>
> Regards,
> Malcolm
>
>
>
> >
>
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--
Re: Django Migrations
Lets get this into 1.1 ;) -dave On Sat, Jan 3, 2009 at 7:02 PM, Brantley Harris wrote: > > 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: Ticket 8764 (Mixing args and **kwargs in reverse() function)
I hadn't intended to come off like an ingrate or be dismissive in my post,
and I apologise for sounding that way; I was frustrated when I wrote it,
which was a mistake. I have great respect for the development efforts for
Django, and the polite comments in response to my post have only increased
that respect.
In essence, I really wanted to see some justification for the choices made,
which I was not able to find discussed anywhere else (even after searching
on this list and on django-users) and I thank you, Malcolm, for taking the
time to detail the thought processes.
The examples from mrts are quite helpful for my particular situation, so
thanks a bunch for that. I think I'll probably end up rewriting my views and
decorators en-mass and making all of my args into keyword arguments, raising
errors when required keywords are not present.
My biggest remaining concern now is with the documentation. The section
about reverse() does not mention this limitation, and perhaps it should.
Additionally, the url template tag documentation seems to demonstrate the
usage of mixed args and kwargs, and perhaps it shouldn't?
http://docs.djangoproject.com/en/dev/topics/http/urls/#reverse
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#url
Should I open a ticket for the documentation changes?
On Wed, Jan 7, 2009 at 2:24 AM, mrts wrote:
>
> On Jan 7, 3:43 am, Malcolm Tredinnick
> wrote:
> > On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote:
> > > There are many instances where, in a complicated implementation of
> > > views, one might want to have a combination of required args and
> > > optional kwargs, and the inability to mix them introduces all sorts of
> > > complexities to the logic of the views that shouldn't have to be dealt
> > > with.
> >
> > I'll disagree with this. Whilst it's easy when one is faced with a
> > particular problem to imagine that it must be a common case, in reality
> > there aren't really that many instances where mixing is required (in
> > fact, I can't think of *any* where it could be compulsory -- it's purely
> > an alternative representation, so rewrites are always possible). There
> > are cases where it can be used, as you witness, but it's not *required*.
>
> E.g. Werkzeug Routes takes this further and handles *only* kwargs.
> Less code, less complexity, less bugs, no problems whatsoever.
>
> It goes as follows (simplified look at request-resolve-response
> cycle):
>
>def __call__(self, environ, start_response):
>resolver = self.url_map.bind_to_environ(environ)
>view, kwargs = resolver.match()
>response = view(request, **kwargs)
>return response(environ, start_response)
>
> +1 to current behaviour or dropping supporting positional args tuple
> passing altogether to get rid of the complexity.
>
> Kilarny, which argument handling problems you have remain unsolved in
> following examples?
>
> >>> def foo(a, b, c=None): # 2 required and 1 optional arg
> ... pass
> ...
> >>> foo(**{'a' : 1, 'b' : 2})
> >>> foo(**{'a' : 1 })
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: foo() takes at least 2 non-keyword arguments (1 given)
> >>> foo(**{'a' : 1, 'd' : 3 })
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: foo() got an unexpected keyword argument 'd'
>
> >>> def foo(a, b, **kwargs): # 2 required and any optional args
> ... pass
> ...
> >>> foo(**{'a' : 1, 'b' : 1, 'd' : 3 })
> >>> foo(**{'a' : 1, 'd' : 3 })
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: foo() takes exactly 2 non-keyword arguments (1 given)
> >
>
--~--~-~--~~~---~--~~
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: Ticket 8764 (Mixing args and **kwargs in reverse() function)
Yes, please do open a ticket for those.
Alex
On Wed, Jan 7, 2009 at 11:37 AM, Luke Graybill wrote:
> I hadn't intended to come off like an ingrate or be dismissive in my post,
> and I apologise for sounding that way; I was frustrated when I wrote it,
> which was a mistake. I have great respect for the development efforts for
> Django, and the polite comments in response to my post have only increased
> that respect.
>
> In essence, I really wanted to see some justification for the choices made,
> which I was not able to find discussed anywhere else (even after searching
> on this list and on django-users) and I thank you, Malcolm, for taking the
> time to detail the thought processes.
>
> The examples from mrts are quite helpful for my particular situation, so
> thanks a bunch for that. I think I'll probably end up rewriting my views and
> decorators en-mass and making all of my args into keyword arguments, raising
> errors when required keywords are not present.
>
> My biggest remaining concern now is with the documentation. The section
> about reverse() does not mention this limitation, and perhaps it should.
> Additionally, the url template tag documentation seems to demonstrate the
> usage of mixed args and kwargs, and perhaps it shouldn't?
>
> http://docs.djangoproject.com/en/dev/topics/http/urls/#reverse
> http://docs.djangoproject.com/en/dev/ref/templates/builtins/#url
>
> Should I open a ticket for the documentation changes?
>
>
> On Wed, Jan 7, 2009 at 2:24 AM, mrts wrote:
>
>>
>> On Jan 7, 3:43 am, Malcolm Tredinnick
>> wrote:
>> > On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote:
>> > > There are many instances where, in a complicated implementation of
>> > > views, one might want to have a combination of required args and
>> > > optional kwargs, and the inability to mix them introduces all sorts of
>> > > complexities to the logic of the views that shouldn't have to be dealt
>> > > with.
>> >
>> > I'll disagree with this. Whilst it's easy when one is faced with a
>> > particular problem to imagine that it must be a common case, in reality
>> > there aren't really that many instances where mixing is required (in
>> > fact, I can't think of *any* where it could be compulsory -- it's purely
>> > an alternative representation, so rewrites are always possible). There
>> > are cases where it can be used, as you witness, but it's not *required*.
>>
>> E.g. Werkzeug Routes takes this further and handles *only* kwargs.
>> Less code, less complexity, less bugs, no problems whatsoever.
>>
>> It goes as follows (simplified look at request-resolve-response
>> cycle):
>>
>>def __call__(self, environ, start_response):
>>resolver = self.url_map.bind_to_environ(environ)
>>view, kwargs = resolver.match()
>>response = view(request, **kwargs)
>>return response(environ, start_response)
>>
>> +1 to current behaviour or dropping supporting positional args tuple
>> passing altogether to get rid of the complexity.
>>
>> Kilarny, which argument handling problems you have remain unsolved in
>> following examples?
>>
>> >>> def foo(a, b, c=None): # 2 required and 1 optional arg
>> ... pass
>> ...
>> >>> foo(**{'a' : 1, 'b' : 2})
>> >>> foo(**{'a' : 1 })
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: foo() takes at least 2 non-keyword arguments (1 given)
>> >>> foo(**{'a' : 1, 'd' : 3 })
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: foo() got an unexpected keyword argument 'd'
>>
>> >>> def foo(a, b, **kwargs): # 2 required and any optional args
>> ... pass
>> ...
>> >>> foo(**{'a' : 1, 'b' : 1, 'd' : 3 })
>> >>> foo(**{'a' : 1, 'd' : 3 })
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: foo() takes exactly 2 non-keyword arguments (1 given)
>>
>>
>
> >
>
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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: Javascript issue on admin interface with prepopulated_fields
Done: http://code.djangoproject.com/ticket/9983 Thank you very much. Adrian Holovaty escribió: > On Wed, Jan 7, 2009 at 9:50 AM, Matias Surdi wrote: >> To solve this, I modified >> ./django/contrib/admin/templates/admin/prepopulated_fields_js.html >> >> replacing the event "onkeyup" on line 5 for "onchange". >> >> Do you think this change could be applied to trunk? Do you want me to >> submit a ticket and/or patch? > > Hi Matias, > > Sure, go ahead and file a ticket in our ticket system, here: > > http://code.djangoproject.com/newticket > > Adrian > > > > --~--~-~--~~~---~--~~ 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: Some tickets that should perhaps get looked at before 1.1
On Jan 7, 11:56 am, "Alex Gaynor" wrote: > I'd like to remind everyone that the policy for bugs is to fix them, they > don't all need to be listed, because the goal is to fix them all. Let me remind everybody that 1.1 is officially only 8 days away. The goal is clearly not achievable in that time :), so a selection has to be made. I'd say bringing up trivial, non-controversial, fully documented and tested bugfixes like I and Tai Lee did, helps in that selection and makes 1.1 a better release. The total ticket mass is just unmanageable and picking ripe fruits for the devs to review and commit should assist, not hinder in achieving that goal. --- Which brings me to a related matter: as there have been no news about Honza and his progress on model validation, I'll semi-champion it (at least until he pops up again OR a core dev steps up to take it upon him/herself OR someone opposes this). I've created a fork of the unofficial git mirror for that purpose at http://github.com/mrts/django/tree/master . Everybody is most welcome to contribute. By semi-champion I mean that I'll contribute as much as I can beside daily job tasks by directly writing code, hanging in #django-dev to discuss things with people interested in helping out and merging other's patches and upstream changes ASAP. Unfortunately I can not warrant that this will be completed it in the short time remaining. Design decisions will eventually appear in the wiki: http://wiki.github.com/mrts/django As of now, I've only merged the latest patch by Honza, so the branch should be rather unusable (trunk has changed considerably in some areas -- neither did the patch apply cleanly nor was it always applicable where it did). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ACL
One of the most requested features/howtos/how-comes/why-nots that show up on the Django users list is Access Control Lists, or row-level permissions. Almost always, the question is about how to get the admin app to use them. This is outside of the scope of the admin app, and that's usually the answer that is given. Would including a built-in contrib app that implements access control lists be outside the scope of Django? I figure a design similar to the current admin site will be needed to create a generic ACL subsystem. An access list would be defined for each app, similar to how an admin site is defined in admin.py. I'm willing to spend some time on this, but I'd like any opinions as to the best way to implement it before I spend more than a weekend or two on this idea. I don't think that there is a Django ACL implementation quite like I have in mind. Most ACL functionality I imagine is written in views that go with a specific app. A standard implementation of ACL in contrib one would allow for more pluggable pluggable apps. Let me know what you think! Thanks! Jeff Anderson signature.asc Description: OpenPGP digital signature
Re: Some tickets that should perhaps get looked at before 1.1
1.1 is not 8 days away, the 1.1 major feature freeze, this means items that are new features on the 1.1 features list. 1.1 final doesn't ship until mid-March, which is quite a bit of time considering that starting on February 15th the only changes that will occur will be bug fixes. Alex On Wed, Jan 7, 2009 at 1:56 PM, mrts wrote: > > On Jan 7, 11:56 am, "Alex Gaynor" wrote: > > I'd like to remind everyone that the policy for bugs is to fix them, they > > don't all need to be listed, because the goal is to fix them all. > > Let me remind everybody that 1.1 is officially only 8 days away. The > goal is clearly not achievable in that time :), so a selection has to > be made. I'd say bringing up trivial, non-controversial, fully > documented and tested bugfixes like I and Tai Lee did, helps in that > selection and makes 1.1 a better release. The total ticket mass is > just unmanageable and picking ripe fruits for the devs to review and > commit should assist, not hinder in achieving that goal. > > --- > > Which brings me to a related matter: as there have been no news about > Honza and his progress on model validation, I'll semi-champion it (at > least until he pops up again OR a core dev steps up to take it upon > him/herself OR someone opposes this). I've created a fork of the > unofficial git mirror for that purpose at > http://github.com/mrts/django/tree/master > . Everybody is most welcome to contribute. > > By semi-champion I mean that I'll contribute as much as I can beside > daily job tasks by directly writing code, hanging in #django-dev to > discuss things with people interested in helping out and merging > other's patches and upstream changes ASAP. Unfortunately I can not > warrant that this will be completed it in the short time remaining. > Design decisions will eventually appear in the wiki: > http://wiki.github.com/mrts/django > > As of now, I've only merged the latest patch by Honza, so the branch > should be rather unusable (trunk has changed considerably in some > areas -- neither did the patch apply cleanly nor was it always > applicable where it did). > > > -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: Some tickets that should perhaps get looked at before 1.1
On Jan 7, 9:59 pm, "Alex Gaynor" wrote: > 1.1 is not 8 days away, the 1.1 major feature freeze, this means items that > are new features on the 1.1 features list. /me puts on a brown paper bag. Right, feature freeze and bug fixing are different things. Can we perhaps agree on a set time when people can start shouting "look at ticket x" (preferably in conjunction with a sprint)? --~--~-~--~~~---~--~~ 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: #3566 Aggregations: Call for testing
On Wed, Jan 7, 2009 at 8:55 AM, Karen Tracey wrote:
> On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
> wrote:
>>
>> I've just pushed some updates to Github that should hopefully fix the
>> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
>> and the decimal/datetime conversion problems). If someone with access
>> to an Oracle test machine can confirm that this has cleaned up the
>> errors, I'd be much obliged.
>
> The aggregation tests now pass. aggregation_regress has one (minor?)
> problem:
>
> Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS ...
> FAIL
>
> ==
> FAIL: Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS
> --
> Traceback (most recent call last):
> File "d:\u\kmt\django\aggregates.git\django\test\_doctest.py", line 2180,
> in runTest
> raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for
> regressiontests.aggregation_regress.models.__test__.API_TESTS
> File
> "D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
> line unknown line number, in API_TESTS
>
> --
> File
> "D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
> line ?, in regressiontests.aggregation_regress.models.__test__.API_TESTS
> Failed example:
>
> Publisher.objects.annotate(avg_price=Avg('book__price')).aggregate(Max('avg_price'))
> Expected:
> {'avg_price__max': 75.0...}
> Got:
> {'avg_price__max': 75}
>
>
> --
> Ran 1 test in 11.757s
>
> FAILED (failures=1)
> Destroying test database...
This appears to be an existing problem in the Oracle backend where
convert_values neglects to convert FloatField values (interesting that
nothing else in the test suite catches this). But is there a reason
that the aggregation field returns an internal type of FloatField when
the field was originally a DecimalField?
Another oddity with this query is that removing the aggregate call
from the above query and leaving only the annotate still results in
floats instead of decimals. It appears that ops.convert_values isn't
getting called in that case. But replace Avg with Max or Sum and it
does get called.
I noticed another bug while testing this: the annotate query above is
modified after the aggregate call, which can be observed by the
following code. I don't think this one is related to the Oracle
backend.
>>> qs = Publisher.objects.annotate(avg_price=Avg('book__price'))
>>> qs.query.as_sql()
>>> qs.aggregate(Max('avg_price'))
>>> qs.query.as_sql()
Ian
--~--~-~--~~~---~--~~
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: #3566 Aggregations: Call for testing
The solution to the fact that aggregate mutates the query is to have
aggregates() do self._clone() like all the other queryset methods do(not
sure how we missed this).
My guess as to why the odd typecasting occurs is because the `is_computed`
check occurs because the check for DecimalField. When it sees is_computed
it just casts to float and returns, I have no idea if this behavior is
correct or not.
Alex
On Wed, Jan 7, 2009 at 2:48 PM, Ian Kelly wrote:
>
> On Wed, Jan 7, 2009 at 8:55 AM, Karen Tracey wrote:
> > On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee <
> freakboy3...@gmail.com>
> > wrote:
> >>
> >> I've just pushed some updates to Github that should hopefully fix the
> >> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
> >> and the decimal/datetime conversion problems). If someone with access
> >> to an Oracle test machine can confirm that this has cleaned up the
> >> errors, I'd be much obliged.
> >
> > The aggregation tests now pass. aggregation_regress has one (minor?)
> > problem:
> >
> > Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS
> ...
> > FAIL
> >
> > ==
> > FAIL: Doctest:
> regressiontests.aggregation_regress.models.__test__.API_TESTS
> > --
> > Traceback (most recent call last):
> > File "d:\u\kmt\django\aggregates.git\django\test\_doctest.py", line
> 2180,
> > in runTest
> > raise self.failureException(self.format_failure(new.getvalue()))
> > AssertionError: Failed doctest test for
> > regressiontests.aggregation_regress.models.__test__.API_TESTS
> > File
> >
> "D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
> > line unknown line number, in API_TESTS
> >
> > --
> > File
> >
> "D:\u\kmt\django\aggregates.git\tests\regressiontests\aggregation_regress\models.py",
> > line ?, in regressiontests.aggregation_regress.models.__test__.API_TESTS
> > Failed example:
> >
> >
> Publisher.objects.annotate(avg_price=Avg('book__price')).aggregate(Max('avg_price'))
> > Expected:
> > {'avg_price__max': 75.0...}
> > Got:
> > {'avg_price__max': 75}
> >
> >
> > --
> > Ran 1 test in 11.757s
> >
> > FAILED (failures=1)
> > Destroying test database...
>
> This appears to be an existing problem in the Oracle backend where
> convert_values neglects to convert FloatField values (interesting that
> nothing else in the test suite catches this). But is there a reason
> that the aggregation field returns an internal type of FloatField when
> the field was originally a DecimalField?
>
> Another oddity with this query is that removing the aggregate call
> from the above query and leaving only the annotate still results in
> floats instead of decimals. It appears that ops.convert_values isn't
> getting called in that case. But replace Avg with Max or Sum and it
> does get called.
>
> I noticed another bug while testing this: the annotate query above is
> modified after the aggregate call, which can be observed by the
> following code. I don't think this one is related to the Oracle
> backend.
>
> >>> qs = Publisher.objects.annotate(avg_price=Avg('book__price'))
> >>> qs.query.as_sql()
> >>> qs.aggregate(Max('avg_price'))
> >>> qs.query.as_sql()
>
> Ian
>
> >
>
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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: #3566 Aggregations: Call for testing
> Refactoring Query.convert_values() into the backend operations would > remove some code duplication, and would also serve to keep all the > data coercion/typecasting code in a common location rather than > spreading some of it into the Query class. However, there are two > things that prevented me from doing this refactor. > ... > Secondly, contrib.GIS has a convert_values() function that invokes > super(GeoQuery, self).convert_values() in the case of an Oracle > spatial backend. Justin - is there any particular reason to call the > GeoQuery base class specifically, rather than invoking > self.connection.ops.convert_values()? Yes, because your subset implementation of `convert_values` does not convert LOB values (which GeoQuery needs). Specifically, geometries are wrapped in a function that returns a CLOB, and the WKT string is obtained from a `.read()` call on the CLOB. I'm -1 on moving conversion operations from the Query class to the backend. However, I'd be +1 if Query.convert_values is kept -- even if it's just a wrapper around self.connection.ops.convert_values. If the conversion functions are _only_ available at the backend level, then it would mean I would have to create distinct spatial database backends every time I want to subclass the convert_values() method. I don't want to have to create distinct database backends just so I can override a single method (DATABASE_ENGINE='gis_postgresql_psycopg2' looks pretty awful to me). > Is GeoQuery likely to have a base class other than OracleQuery in the > Oracle case? No; unless, of course, the backend requires a custom Query class like Oracle does -- which would mean any future backends without LIMIT/ OFFSET and spatial support would also subclass from the backend's Query class. -Justin --~--~-~--~~~---~--~~ 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: #3566 Aggregations: Call for testing
On Wed, Jan 7, 2009 at 7:46 AM, Russell Keith-Magee wrote: > There is some potential for further refactoring here, especially with > regards to the decimal/datetime conversion routines. The Oracle > DatabaseOperations.convert_values() function that I added for > aggregate support is an almost perfect subset of the features in the > Oracle Query.convert_values() function. > > Refactoring Query.convert_values() into the backend operations would > remove some code duplication, and would also serve to keep all the > data coercion/typecasting code in a common location rather than > spreading some of it into the Query class. However, there are two > things that prevented me from doing this refactor. > > Firstly, Query.convert_values() uses a lot of isinstance() calls on > fields, rather than checking the internal type of the field. > Aggregates use the internal type because aggregates aren't actually > fields, but they do return database types. Ian - can you see a problem > with converting the isinstance(field, DecimalField) calls to > field.get_internal_type() == 'DecimalField' etc? Yes - field could be None, resulting in an AttributeError. I see no problem replacing them with (field and field.get_internal_type() == 'DecimalField'). Currently we seem to be calling convert_values twice for each aggregate value of an annotate query. First, query.convert_values gets called from resolve_columns with a None field. Later, ops.convert_values gets called with the actual field. The reason I bring this up is that the former call might interfere with the latter call. For example, if an aggregate value of a DateTimeField has a time component of exactly midnight, the former call will incorrectly assume it's meant to be a date value and cast it as such. The latter call would then need to be intelligent enough to reverse it. In refactoring these methods, would it be an extraordinary effort to also refactor the calls so that the former call never happens? Ian --~--~-~--~~~---~--~~ 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: ACL
On Jan 8, 6:57 am, Jeff Anderson wrote: > One of the most requested features/howtos/how-comes/why-nots that show > up on the Django users list is Access Control Lists, or row-level > permissions. Almost always, the question is about how to get the admin > app to use them. This is outside of the scope of the admin app, and > that's usually the answer that is given. > > Would including a built-in contrib app that implements access control > lists be outside the scope of Django? > > I figure a design similar to the current admin site will be needed to > create a generic ACL subsystem. An access list would be defined for each > app, similar to how an admin site is defined in admin.py. I'm willing to > spend some time on this, but I'd like any opinions as to the best way to > implement it before I spend more than a weekend or two on this idea. > > I don't think that there is a Django ACL implementation quite like I > have in mind. Most ACL functionality I imagine is written in views that > go with a specific app. A standard implementation of ACL in contrib one > would allow for more pluggable pluggable apps. Django Granular Permissions is quite flexible and its usage does not depend on the admin or any other app. It uses Generic Relations and can be added to models in the Django admin with Generic Inlines. [1] http://code.google.com/p/django-granular-permissions/ cheers Matthew -- Matthew Flanagan http://wadofstuff.blogspot.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: #7210 - F() syntax, design feedback required.
On Thu, Jan 8, 2009 at 1:36 AM, Alex Gaynor wrote: > I've spent some time looking at this trying to implement expansion of > related fields as Russ and I discussed last night. I have a few questions > about the design choice that was implemented, why didn't you choose to go > with this evaluator class in place of a mechanism more similar to the way > aggregates are implemented. An aggregate is a single class, so there isn't much overhead involved in creating an SQL-specific duplicate of the aggregate. An expression, however, is a full tree. Duplicating a tree is a more expensive operation, so I opted for a mechanism that interprets the tree on demand, rather than duplicating the tree. > Specifically the issue that has come up is that > whatever goes into the Queries where attribute needs to know the table alias > that it's going to be on, and while this can quite easily be accomplished by > passing it to it at the time evaluate() is called when bump_aliases is > called(on an update query for example) this necessitates the relabeling of > all the aliases, right now there's a hook for this(that aggregates make use > of), but that can't be used since QueryWrapper is being used and opaque > strings of SQL are being passed around. Essentially the question boils down > to why don't we defer creating the SQL until it's actually needed? A combination of historical and lack of need. Nicolas' code invoked evaluate when the filter/update clause was added, and since F() clauses on local attributes aren't subject to re-aliasing, it never arose as an issue. Deferring SQL creation strikes me as the right thing to do in this case. My initial reaction is that the approach required is Rather than having a single evaluator class, I suspect we may need to insert instances of SQLEvaluator that remember the root of expression trees into the SQL-side of the query where evaluate() is currently being called. This would make expressions more like Aggregates. F() objects would have an add_to_query() function, and you would call add_to_query() on the root of the query expression to create an Evaluator instance. as_sql() on the SQLEvaluator would then expand the query expression at time of use. 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://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #7210 - F() syntax, design feedback required.
Another problem that occured to me is precisely that, F() objects are trees,
so what happens when I do:
Model.objects.filter(field=F('related_model1__field')+F('related_model2__field'))
clearly the process for adding in calls to setup_joins() gets a little more
complex. Hopefully I'll have some more time to look at it either tonight or
tomorrow, but I'm juggling a few patches at present, and as you said this
feature isn't required for F() to make it into 1.1.
Alex
On Wed, Jan 7, 2009 at 5:22 PM, Russell Keith-Magee
wrote:
>
> On Thu, Jan 8, 2009 at 1:36 AM, Alex Gaynor wrote:
> > I've spent some time looking at this trying to implement expansion of
> > related fields as Russ and I discussed last night. I have a few
> questions
> > about the design choice that was implemented, why didn't you choose to go
> > with this evaluator class in place of a mechanism more similar to the way
> > aggregates are implemented.
>
> An aggregate is a single class, so there isn't much overhead involved
> in creating an SQL-specific duplicate of the aggregate. An expression,
> however, is a full tree. Duplicating a tree is a more expensive
> operation, so I opted for a mechanism that interprets the tree on
> demand, rather than duplicating the tree.
>
> > Specifically the issue that has come up is that
> > whatever goes into the Queries where attribute needs to know the table
> alias
> > that it's going to be on, and while this can quite easily be accomplished
> by
> > passing it to it at the time evaluate() is called when bump_aliases is
> > called(on an update query for example) this necessitates the relabeling
> of
> > all the aliases, right now there's a hook for this(that aggregates make
> use
> > of), but that can't be used since QueryWrapper is being used and opaque
> > strings of SQL are being passed around. Essentially the question boils
> down
> > to why don't we defer creating the SQL until it's actually needed?
>
> A combination of historical and lack of need. Nicolas' code invoked
> evaluate when the filter/update clause was added, and since F()
> clauses on local attributes aren't subject to re-aliasing, it never
> arose as an issue.
>
> Deferring SQL creation strikes me as the right thing to do in this
> case. My initial reaction is that the approach required is Rather than
> having a single evaluator class, I suspect we may need to insert
> instances of SQLEvaluator that remember the root of expression trees
> into the SQL-side of the query where evaluate() is currently being
> called.
>
> This would make expressions more like Aggregates. F() objects would
> have an add_to_query() function, and you would call add_to_query() on
> the root of the query expression to create an Evaluator instance.
> as_sql() on the SQLEvaluator would then expand the query expression at
> time of use.
>
> Russ %-)
>
> >
>
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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: #3566 Aggregations: Call for testing
On Wed, 2009-01-07 at 13:28 -0800, Justin Bronn wrote: [...] > I'm -1 on moving conversion operations from the Query class to the > backend. However, I'd be +1 if Query.convert_values is kept -- even > if it's just a wrapper around self.connection.ops.convert_values. If > the conversion functions are _only_ available at the backend level, > then it would mean I would have to create distinct spatial database > backends every time I want to subclass the convert_values() method. I > don't want to have to create distinct database backends just so I can > override a single method (DATABASE_ENGINE='gis_postgresql_psycopg2' > looks pretty awful to me). The general principle that Justin's mentioning here: providing a general method that possibly calls a backend method is something I like as a rule. It allows one to provide some non-backend-specific extensions more easily. So I agree with Justin in terms of how any refactoring might happen: leave a Query-level entry point exposed. > > Is GeoQuery likely to have a base class other than OracleQuery in the > > Oracle case? > > No; unless, of course, the backend requires a custom Query class like > Oracle does -- which would mean any future backends without LIMIT/ > OFFSET and spatial support would also subclass from the backend's > Query class. MS SQL Server support being one case that's likely to crop up as an external project at some point. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ACL
On Wed, 2009-01-07 at 12:57 -0700, Jeff Anderson wrote: > One of the most requested features/howtos/how-comes/why-nots that show > up on the Django users list is Access Control Lists, or row-level > permissions. Almost always, the question is about how to get the admin > app to use them. This is outside of the scope of the admin app, and > that's usually the answer that is given. > > Would including a built-in contrib app that implements access control > lists be outside the scope of Django? It may not be. However, this isn't really the right question to ask. The right question is "why has nobody built the kick-ass implementation that everybody needing this is prepared to walk across hot coals to use because it's so wonderful?" Something like this doesn't need to be in Django. Maybe not ever, but certainly not initially. Django is designed so that external applications are easy to develop and don't need core modifications. If it's built and isn't included in Django, nobody is any worse off, because it still exists. For good reason, we try very hard not to give advance commitment to acceptance of anything before it exists externally. There have historically been some very rare exceptions, but are just that: exceptions. If, in the process of developing said application, problems appear that justify generalisations of abstractions being made to core, discussions appear here and things happen. That has happened in the past and will happen again in the future. In this case, for example, it might turn out that some kind of subclass overriding isn't possible in the admin and making something finer-grained to allow extensions might not be a bad idea. I'm also thinking that requiring evidence of people walking across hot coals in order to use an application is probably a good pre-requisite for inclusion in django.contrib. Regards, 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ACL
2009/1/7 Malcolm Tredinnick : > > I'm also thinking that requiring evidence of people walking across hot > coals in order to use an application is probably a good pre-requisite > for inclusion in django.contrib. > +1 The gmail ads are conveniently offering me 'Firewalk Teacher Training' and 'Find a Fire-Walk near you', so this shouldn't be too hard to organise :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
