Re: issues with generic relation item lookup
On Sat, 2008-02-16 at 15:45 -0800, Chris Drackett wrote: > I am having two issue with generic relations. [...] > any ideas on how to fix this. I think this bug might be > related, but I can't tell: > > http://code.djangoproject.com/ticket/6051#preview There are a couple of bugs like this with generic relations. I'm pretty sure #6051 is a dupe or two or three others (tickets that address multiple issues in one ticket like that are always annoying because they often only partially overlap). They're being worked on at the moment. Particularly the issue with needing to use content types in lookups is actually a lot fiddlier than it looks at first glance. We want a solution that works in general -- for other fields that map one Django field to multiple db columns -- not a symptom-fixing workaround that only works for generic relations. That's design work in progress. All I can say is "wait a little longer, please". Regards, Malcolm -- Always try to be modest and be proud of it! http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django ORM performance patch. Fixes #5420, #5768
Per my patches and what I believe Malcom has done with qsrf, the syntax for related fields was field__related__name, and yes, you would repeat this over and over, but it keeps it consistant. I would like a values-like method to return partial objects, and then requesting any field thats not "filled" would hit the db in some fashion, but that's another story. On Feb 15, 3:42 am, Dima Dogadaylo <[EMAIL PROTECTED]> wrote: > On 15 Feb, 12:30, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > When Adrian > > proposed that API, he realised that almost always you're going to be > > pulling back all of the fields or almost all of them. Once a database > > has read a row to access some of the data, accessing all of the data in > > the row is close to zero overhead. It's already had to read the block > > off disk, for example, which is many kilobytes in size. Only for either > > extremely large fields or for fields that need a large amount of > > post-processing to be useful (such as polygon fields) is it really a win > > to micro-manage what is pulled that. > > > For most non-trivial SQL queries with modern databases, constructing > > (extracting) the output columns, unless they are complex computations, > > is a very small fraction of the timeslice devote to the query execution. > > It's true but not all true. > > Often it's have sense to exclude even small non-used fields, because > when you do joins with GROUP BY or similar for final 100 rows you may > have temporary in-memory or even disc-table from 100*100 rows and size > of each rows really matters. > > Then not only db-stage consume resources, but also network bandwidth > is consumed, python database adapter consumes a lot on converting raw > char stream to never used python objects, memory is wasted. It's > extremely important on limited VPS-hostings. > > However, IMHO such technical details isn't important because ORM > should not assume that things are "good enough". With ideal ORM I > should be able to do _all_ that I can do with raw SQL. Everyone needs > are special, same ORM will be good for small project but unacceptable > for big project if ORM assumes that "this" and "those" limitations are > acceptable for all. > > >> That's why the API is to specify what to exclude, rather than what to > > include. I tend to agree with the proposal, too. From a performance > > management perspective, it's going to be easier to use that way. > > I agree that in many cases exclude() may be useful and probably it's > worth to add it also, but as I already wrote in my blog post, this > patch come from real experience when you don't have "tutorial-like" > models and when there is conscious data redundancy in many tables. > It's typical task to show object_list and object_detail for any model > and for each object_list I know exactly what fields I need and usually > it's 3-5 fields from model itself and 2-3 fields from related models. > I strongly believe that API should give me ability to receive only > those fields even if all database severs will work with speed of > light. > > > This isn't "standard Django lookup syntax", though. It's some entirely > > new lookup syntax you created. There's nowhere in the current lookup > > hierarchy that uses this method for referring to fields in another > > model. Reusing the existing syntax makes more sense. It's less for > > people to learn and it's less restrictive: with the double-underscore > > syntax, I can list the fields in any order, since they're all positional > > arguments. Your syntax has normal fields as positional arguments (so > > they must come first) and related fields as keyword arguments that take > > a sequence. > > I sure you know Django lookup syntax much better than me, but IMHO > your proposition violates DRY, because if I need to select several > fields from related model I need to repeat and repeat > "user__address__fieldname". Your proposition is close to original SQL > syntax of SELECT statement and due to this issue your proposition > should be accepted probably even if it violates DRY but keeps > conceptual integrity with underlaying SQL level. > > I think it's only several lines task to change syntax from > fields(*fields, **related_fields) to fields(*args). So if sometimes > core developers change own mind about fields() method I can add to my > patch plain lookup syntax support. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug saving NUL character?
Should I create a ticket on trac for this? Alexandre Martani On 11 fev, 19:20, Robert Gravsjö <[EMAIL PROTECTED]> wrote: > Patryk Zawadzki wrote: > > --- 8< --- > > > What kind of injection? It did not terminate the SQL query, just the > > contents of one field. SQL termination in the middle of a quoted > > string would result in a failed transaction. Also, AFAIR Django uses > > prepared statements so there's no possibility to execute code from a > > Are you sure about this? Any reference (docs, code)? AFAICT django does > not use prepared statements. > > Regards, > /roppert > > > bound variable. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
issues with generic relation item lookup
I am having two issue with generic relations. I have the following models: - category (has just an owner that links to the User model) - tag (has a FK link to category) - posts, links (models for posts and links that are linked to the tag model with a generic relation) the problem I am having is when I do the following: user_posts = Post.objects.filter(tags__category__owner=request.user) I get both the correct posts along with that aren't actually attached to the user. These extra posts have the id of links that that user is attributed to. any ideas on how to fix this. I think this bug might be related, but I can't tell: http://code.djangoproject.com/ticket/6051#preview any ideas? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New field lookups
Julian, The django-developers mailing list for discussing the development of Django itself; django-users is the appropriate forum for this type of question. There are no lookups for hour, minute, second because this functionality may be accomplished by utilizing a `range` lookup with Python `datetime` objects (which may be specified down to the hour, minute, and second). See: http://www.djangoproject.com/documentation/db-api/#range -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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
New field lookups
Hi there, writing a statistic-software i do need field lookups like day, year but more specific: hour, minute, second. what about those? can i modify my django-app to add them? regards julian --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket #6548 - django behind apache ssl proxy
Hi, I've posted a ticket about http module, but as requested by Simon Greenhill, I also post the ticket description here (it is probably subject to discussions ;) ). I've seen some code in http/__init__.py:get_host function to handle X- FORWARDED-HOST that could be added by an apache proxy. Unfortunately, there is no way to determine if proxy is acceded in https or http, so an issue occures when django wants to build an url for some Redirect : the url is built using the X-FORWARDED-HOST, but always assume that the proxy is non-SSL. I think there could be some solutions to solve this issue : * Remove test for X-FORWARDED-HOST in get_host, apache mod_proxy is designed to rewrite Location headers (used in redirect) * If some people want to have X-FORWARDED-HOST handled in get_host, then add a setting to enable or disable it * add a setting like 'HTTPS_PROXY=on' that would work like HTTPS=ON -- Lauréline Guérin. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
