GenericRelation setting and behaviour due to .clear() from __set__ in ReverseGenericRelatedObjectsDescriptor
This is probably not a bug and just a consequence of what I'm trying to do (and probably not doing it in a very good way), so this is not me saying "something needs to be fixed or changed", just observing. I have a model class of "Document" which has a file field on it and is set up to have a GenericForeignKey field which can be blank. I have a variety of other classes which have GenericRelation fields to point back to it. What I want to do is treat them a bit like a ManyToMany field on a form. The UI for the GenericRelation fields that point to documents consists of listing any existing documents set in the field, allowing documents to be removed from the field and also providing a popup dialogue which allows new documents to be created (they get saved through the popup dialogue but with the GenericForeignKey field set to blank). The first thing I hit was that "GenericRelation" fields are forced to to have "editable" set to False, so the model form creation skips 'em. So I declared them on the form as ModelMultipleChoiceField (for the purposes of having something vaguely sensible there) but using my own custom code to render the widget. When the form is submitted the value for the widget consists of id values for the Document objects selected and ModelMultipleChoiceField's clean method turns it into a list of Document objects. So far so good. save_m2m fires and so __set__ gets called for the GenericRelation field and that's where I hit a problem because __set__ assumes that the value being assigned to it contains none of the prior values so calls .clear() before then doing .add() for each item. So if you had a field called "somegenericrelation" on an instance which had some values (i.e. objects related via the relation) then doing "instance.somegenericrelation=instance.somegenericrelation" will delete all the items and then add them ... Now as ..save() on a model instance will do an "INSERT" if the record doesn't exist when what would happen usually is that the table entries (in my case for Document) would be deleted and reinserted. As "Document" has a file field what happens is the file gets deleted on disk by the file manager during the deletion and then of course although the record for the Document gets recreated the file is now gone. So from this I suspect having a GenericRelation field appear on a form is bad and I'm probably doing something I shouldn't - alternatively maybe it's an area/use of contenttypes that's been overlooked? I also suspect that assigning to a GenericRelation field a list of values that includes items already assigned to it is bad and shouldn't be done (and because I'm doing a bad thing in using it on a form I'm making the django form stuff do this bad thing itself) - alternatively maybe __set__ on ReverseGenericRelatedObjectsDescriptor could be a bit more clever and not delete any objects its going to add back again with .add. Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Subselect in query set .extra(tables=...)
A couple of times I've wanted to be able to pass in a sub query as a
table in query_set.extra to be able join in some extra information but
have been thwarted as the query code always insists on quoting what
you pass in as tables to .extra (i.e. it assumes it's always table
names).
Back in 2005 with issue #967 someone put in some code to allow this,
but as part of qs-rf this was dropped (although the way it was decided
whether to quote something back then looks a bit clunky).
With postgres at least, if you pass in a subselect to the FROM it has
to have an alias, so if the tables argument to extra were to support
subselects it would need to allow something like "(SELECT foo FROM
blah) AS alias_of_subsel" being passed in.
I can't see how to pass in a subselect via .extra with Django 1.1 - if
anyone knows how to that would be useful. It seems unnecessarily
limiting for .extra not to allow subselects to be passed in where the
database engine supports it. A simple fix (although I don't know if it
has any bad consequences I can't think of) at least for postgres would
be if the backend's quote_name function didn't quote what's passed in
if it begins with "(" as subselects in the from in postgres always
have to be in parenthesis. I'm going to monkey patch
connection.opts.quote_name in my code for now to behave that way.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Help request: postgresql_psycopg2 connection problem under wsgi (but under runserver and dbshell its fine!)
My guess is that your connection string specifies connecting as user "acacian", specifies no password and that you've been logged in as a user with the same name to run runserver. The default configuration of postgresql allows users to connect as a postgresql user of the same name as them without a password (over local sockets). I suspect the apache process is not running as user "acacian" thus password-less authentication is failing. To fix it you'll need to fiddle around with postgresql authentication settings (unless you want to change the user which apache runs as). On Apr 19, 11:54 pm, Daryl wrote: > Hello, > > I'm getting the following error when deployed under mod_wsgi > > File "/usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg/ > django/db/backends/postgresql_psycopg2/base.py", line 98, in _cursor > self.connection = Database.connect(**conn_params) > OperationalError: FATAL: Ident authentication failed for user > "acacian" > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: pg_get_serial_sequence("unknown", "unknown") - revision 13336
The calls to pg_get_serial_sequence were added in to fix #8901 and I noted on that issue that the call wasn't available on PostgreSQL prior to 8, that Django made no claims about which PostgreSQL version it requires as a minimum, but that version 7 was rather old these days with version 8 having been around for 5 years now. Note that I think it is possible to create pg_get_serial_sequence for PostgreSQL 7: http://pgfoundry.org/tracker/index.php?func=detail&aid=1000463&group_id=1000151&atid=616 (perhaps you could test that Federico?) As noted above, Version 8 was first released in 2005. Version 7.4 has still had bug fixes by the PostgreSQL community to date however to quote from the release notes "The PostgreSQL community will stop releasing updates for the 7.4.X release series in July 2010. Users are encouraged to update to a newer release branch soon. " Russ - I guess the choice is either a note in the Django docs/release notes about this issue and suggesting anyone on 7 adds in pg_get_serial_sequence as per the above link (if that does indeed work) or alternatively change the code touched by #8901 such that it only adds the calls to pg_get_serial_sequence for version 8 onwards and for version 7 it either reverts to guessing the sequence name as it used to (with a caveat in the documentation that for long model or field names there will be the errors that #8901 fixes) or alternatively it calls the SQL listed in the above pgfoundry link to fish out the sequence names itself (it could call that sql always regardless of postgresql version but I guess there's a tiny risk that in a later version of postgresql the catalog structure could change so calling pg_get_serial_sequence is preferred when it's available). On Jun 9, 11:27 am, Federico Capoano wrote: > I have PostgreSQL version 7.4.27 on my server. The reason for which I > use this version is that is the latest version available for webmin > and my VPS use it. > What can I do? > > I checked the release notes and I didn't notice anything about this > bit. Before upgrading to the last revision I had probably the trunk > equivalent to the just released 1.2 > > Thanks for your help. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: pg_get_serial_sequence("unknown", "unknown") - revision 13336
... Replying to my own post on this bit... of course the older Django 1.1.x can still be used with the older PostgreSQL 7 without hitting this issue regardless as I'm assuming the patch for #8901 isn't being applied back to the 1.1 series :). Perhaps worth being explicit in the Django documentation for 1.2 about which PostgreSQL version is required as a minimum (both for the benefit of users and also for anyone submitting patches to the PostgreSQL back-end so they know what they have to work with!). > Russ - I guess the choice is either a note in the Django docs/release > notes about this issue and suggesting anyone on 7 adds in > pg_get_serial_sequence as per the above link (if that does indeed > work) or alternatively change the code touched by #8901 such that it > only adds the calls to pg_get_serial_sequence for version 8 onwards > and for version 7 it either reverts to guessing the sequence name as > it used to (with a caveat in the documentation that for long model or > field names there will be the errors that #8901 fixes) or > alternatively it calls the SQL listed in the above pgfoundry link to > fish out the sequence names itself (it could call that sql always > regardless of postgresql version but I guess there's a tiny risk that > in a later version of postgresql the catalog structure could change so > calling pg_get_serial_sequence is preferred when it's available). -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: pg_get_serial_sequence("unknown", "unknown") - revision 13336
Hi Federico, >From the discussion on django-developers it looks like the patch will be reverted soon so you may find in due course things will start working again with SVN for the 1.2 branch (however with Django 1.3 support for 7 will likely be dropped). It doesn't sound like you particularly need to be using the SVN version, since 1.2 has been released, so I'd suggest just grabbing 1.2.1 and using that instead of SVN for your blog as that doesn't have the patch which broke things working with postgresql 7. In terms of upgrading from 7 to 8 on debian it's the same as upgrading from 7 to 8 on any system, you have to do it via data dumps and imports rather than postgresql being able to upgrade the data files in- place. There were some changes in the dump formats so to do a big jump safely unfortunately what you really need is to run the pg_dump command from version 8 talking to your version 7 server, and even then with the later versions of 8 if you were using the tsearch2 full-text index module there can be some problems as it's moved to being in the core. Have a look at the section of the postgresql manual on migration and if you want to know the gory details of any backwards-incompatible changes also at the release notes for the 8.0 release and every minor release up to the version you're intending to run (you can skip over the point release release notes tho' as they don't tend to introduce backwards-incompatibilities in point release changes). It will, in part, depend on whether your version of webmin works with version 8. I guess you'll have to make the jump to 8 eventually tho' even if you hold off for now :) Matt On Jun 9, 2:53 pm, Federico Capoano wrote: > I see. I think I'd like to upgrade postgresql .. but I don't know what > would happen with webmin. > Maybe I'll go to ask to the webmin support. > > Do you think upgrading from 7 to 8 is a difficult task on debian? > > I also think it should be written in the documentation and release > notes. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: problem with encoding "utf-8", postgresql 8.3
I can't help shed much light on the problem, but it's worth saying that 0xefbfbd is the sequence for the UTF-8 BOM (Byte Order Mark), see http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8 and is shown as a zero-width invisible character. It could be that however you're getting the "ó" onto the URL when you type it directly is somehow dragging the invisible character along with it. I notice you're using utf-8 as the character set for your pages - I think you're asking for trouble doing this since the utf-8 character set allows for more characters than latin1 supports so it's possible for your users to enter characters into the search form which won't map into latin1 (this may not be a risk with your user base, granted) - if you can't change the database character set I think you'd be safer using latin1 for what you send and receive to the browser via setting DEFAULT_CHARSET and the content-type header, although django will still continue to use unicode/utf-8 internally. See http://docs.djangoproject.com/en/dev/ref/unicode/ ... basically it's a pain if you don't just stick with utf-8 :). On Jun 9, 11:15 pm, refreegrata wrote: > Hello list. I'm a newbie with django and have a problem with the > encoding. I use postgreSQL 8.3 with psycopg2. My database is in latin1 > and i can't change this to utf-8(i don't have the permission), however > the database have a client-encoding in utf-8. I think this solves the > problem. > > > When i type "ó" in the input box all works fine, and returns all > coincidences and the url says "http://localhost/prueba_1/search/?q=ó"; > However when i type directly in the url "http://localhost/prueba_1/ > search/?q=ó" and press enter Django throw an error > "Caught DatabaseError while rendering: carácter 0xefbfbd de > codificación «UTF8» no tiene equivalente en «LATIN1»" > and the url in the browser change to "http://localhost/prueba_1/ > search/?q=%F3". Why happens that?, I'm really confused with the themes > about the encoding. > > That's is my question, thanks for read, and sorry for my poor english -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: HttpRequest.DELETE implemented?
>From glancing at the code for the modpython and wsgi core handlers I think django always puts the URL arguments into "request.GET" regardless of method (i.e. it's not restricted to just GET and POST requests, since query strings on URLs can exist for any method) where as "request.POST" will only be populated from a POST. So you would do: if request.method=='DELETE': MyModel.objects.get(id=request.GET['id']).delete() (assuming, based on your code, that your client software is genuinely doing an HTTP DELETE request and that you have an id in the query string part of the URL) On Jun 14, 10:48 am, kalinski wrote: > Hi Djangos, > > is this working like expected with recent django version:? > > def myview(request): > if request.is_ajax: > if request.DELETE #or alternatively if request.method=='DELETE': > MyModel.objects.get(id=request.DELETE['id']).delete() > > or do i have to go through POST and for example hidden form fields? > > thanks > kalinski -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: UnicodeDecodeError (ordinal not in range) when deleting an inline item - 1.2.1
> File "/usr/lib/python2.3/site-packages/sorl/thumbnail/utils.py", > line 36, in all_thumbnails > if os.path.isfile(os.path.join(path, file)): > > File "/usr/local/lib/python2.6/posixpath.py", line 68, in join > path += b > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position > 13: ordinal not in range(128) What this error means is that either path or b is a normal (non- unicode) string and contains a non-ascii character (perhaps the character Ã) at position 13 and the other one is a unicode string. When python concatenates a non-unicode string and a unicode string it tries to convert the non-unicode string to unicode using the ascii encoding. As to which is which... well I've had a brief glance at the sorl code and it'll take more time than I can be bothered to spend to figure out which :). My guess is that the filename coming from Django is coming in as a unicode string, although sorl has a number of normal string literals in it I suspect that's making it through as unicode... So that perhaps leaves your sorl path configurations - perhaps you're not configuring the directory paths for sorl using unicode strings and that's causing the problem. Matt -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: how to use render_to_response, ajax and javascript variables
Perhaps instead of using render_to_response to generate the response, render the template output to a string and then stuff that in the data structure that you serialise to json along with the other data? Regards, Matt On Jun 16, 1:17 pm, Alex wrote: > > But the problem I have - and I may be thinking about this in the wrong > way - is that I also want to pick out some variables from the response > to use in my js success callback. If I wasn't using django templating > this could be straightforwardly achieved with a JSON response parsed > client side. So my difficulty is that I want both a rendered template > response and some JSON response in the same callback... I have thought > about 'enriching' the render_to_response context with these additional > variables, inserting them in hidden html fields and then querying the > dom for their values - but that feels awkward and also means the > response has to be added to the dom before the js can act on their > values. > > This seems like a familiar nut that must be well documented > somewhere... :) any help, pointers very appreciated. > > Thanks > Alex -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: mod_wsgi sometimes gives error on first reload but not thereafter
On Jun 16, 3:07 pm, Chris Seberino wrote: > On Jun 15, 6:42 pm, Graham Dumpleton > wrote: > > > This occurs when Apache is first reading HTTP headers for request and > > long before it hands it off to any Django application or even > > mod_wsgi. > > Is there anything I can do about this? I assume this means we should > pronounce the mod_wsgi setup I have good and not bother trying to use > your sample script after all like you discussed in previous email? > Since it looks like a problem with the http communication between the browser and the server you might find it worth hooking something like TCPWatch (http://hathawaymix.org/Software/TCPWatch) in between the two and look at what's going back and forth to try spot where the problem is being introduced. On the face of it, it seems most likely it's your copy of firefox misbehaving for some reason! Matt -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: how to use render_to_response, ajax and javascript variables
Django has an escapejs filter so if you're using a template to
generate json you'd be safer doing, e.g.:
"first_name":"{{ one_member.first_name|escapejs }}"
That way if someone sticks something untoward (like a double quote) in
your first_name or last_name fields it won't break things :).
For the rolling up of HTML and JSON I personally would use a template
for the HTML but I wouldn't bother with it for the JSON as typically
the stuff you want to chuck back in JSON would be most naturally (I
think) built up as a python data structure (e.g. dict of values) which
you use simplejson (which is included with Django) to convert into
json.
from django.utils import simplejson
returnData={
'success':1,
'htmlData:template.render(context),
'someListData':['Item 1','Item 2']
}
return HttpResponse(simplejson.dumps(data),mimetype='text/plain)
That way simplejson'll take care of sorting everything out :). If you
want to dump out django objects as json too then look at the
documentation for serialising django objects.
Regards,
Matt
On Jun 17, 8:42 am, Ian McDowall wrote:
> Here is the template:
>
> {"results":[
> {% for one_member in member_set %}
> {
> "id":"{{one_member.id}}",
> "username":"{{one_member.username}}",
> "first_name":"{{one_member.first_name}}",
> "last_name":"{{one_member.last_name}}"},
>
> {% endfor %}
> ]}
>
> I choose text/plain deliberately but you might choose text/json (or
> something else). if you embed HTML in JSON then you will need to be
> careful that the HTML does not itself contain characters that break
> the JSON (e.g. quotation marks).
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: how to use render_to_response, ajax and javascript variables
I was just copying Ian's choice of mimetype - see Ian's comment above "I choose text/plain deliberately but you might choose text/json (or something else)."... Although it's worth pointing out that "text/json" shouldn't be used, since "application/json" is, as you rightly point, the mimetype for json data :). On Jun 17, 9:18 am, Dmitry Dulepov wrote: > > Small correction: mime type should be application/json. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: how to use render_to_response, ajax and javascript variables
On Jun 17, 10:31 am, Ian McDowall wrote: > > In some cases, I don't use templates to build a JSON response. It can > be straightforward to write it as a string inline. I don't personally > yet use the built in Python JSON module as I don't want to limit the > Python versions that I can deploy with but I am sure that I will move > to this at some point. Django comes with simplejson as django.utils.simplejson (it was in 1.0) - and to quote from the docs for 1.1 and 1.2: The Django source code includes the simplejson module. However, if you're using Python 2.6 (which includes a builtin version of the module), Django will use the builtin json module automatically. If you have a system installed version that includes the C-based speedup extension, or your system version is more recent than the version shipped with Django (currently, 2.0.7), the system version will be used instead of the version included with Django. Regards, Matt -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Selling Django
> plug and play. A manager/developer making the decisions on a platform > for their next project should be able to download django and just plug > in the functionality he/she needs. Dependencies will exist but that's > normal. > If all that would happen django would be an easy choice for anyone, > well absolutely for me. Without these I spent months swinging back > and forth on various decisions because the above situation does not > exist for django. The market you talk about sounds like one where things like Pinax/ Satchmo/LFS are a substantial match for their requirements and who can then benefit from the power of Django in extending beyond the capabilities of what those apps provide. The drupal/joomla/plone/ wordpress type market, perhaps? The kinds of applications I build in Django aren't in the style of public-facing websites, they're web-based applications where few if any of the facilities from Pinax, Satchmo or LFS are of any interest to me. In fact for me one of the appeals of Django was that it didn't try to do too much for me (i.e. it didn't quickly start to get in the way like, say, drupal tends to once you get beyond a certain point). I quite like the skeleton proposal Russ sketches out in the mail you replied to - that sounds like it would have more of a general reach rather than trying to get into the drupal/joomla/plone/wordpress space. Regards, Matt -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Selling Django
Richard, That is where most people who are looking for something *in that space* look first - i.e. they have a set of requirements where those platforms are a good fit for what they're trying to do, but it isn't the only space. Those people aren't the people who pay my wages at present because, as I said, I'm currently not building applications where any of those would be a good fit :). I originally selected Django because I was looking for something that was specifically not in the space that, say, drupal is in as although some of the facilities it and other vaguely similar frameworks provide could have been of use, a lot of what they provided wasn't a good fit or was just irrelevant and if using them I would have been forced into doing things a less-than-ideal way. As you got more specific in this thread your approach seemed to be orientating towards "selling" Django by "selling" Django-based applications of a certain type (a bit like "selling" Zope by "selling" Plone, perhaps?) and thus the path to that being to sort out those applications. I'm not saying it's not a valid approach (having great re-usable applications is no bad thing), I'm just saying it's not the only approach and that the space you talk about is not the only requirement space where Django is useful. Regards, Matt On Jun 17, 3:06 pm, Richard Shebora wrote: > @Matt > > You are correct. The "drupal/joomla/plone/wordpress space" does exist > and it is where most people (non-developers) look first. These are > the people who need to perceive django in a more positive light if the > goal is to increase django market share. They are the people who hire > you and I. If not, it's a moot point. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Selling Django
Yo-Yo Ma, You must be reading a different thread to me... Or rather I don't see it in quite as negative terms as you do and I'm a bit baffled as to how you've interpreted it quite so strongly! Richard's OP was indeed not saying that we should go out and advertise that it's a great CMS but he did mention some CMS and his follow-up post did indicate that the approach he was thinking about was oriented more towards those with a requirements for CMS-type-things where applications to do a lot of it could already be reused. In the responses from others in the thread I see enthusiasm for raising the profile of Django (and making it easier for people to make an informed decision about whether it's a good fit for their requirements) but also musings on the "market" for Django and about the re-usable applications (in particular those to assist in CMS-type-things) being a related, but separate, strand to Django core. "They don't get jobs usually which is why they work for free." did make me laugh, so nice one ;) Regards, Matt On Jun 18, 1:16 am, Yo-Yo Ma wrote: > This thread shows a very prevalent side of most developers that makes > me ashamed to tell people that I'm a developer. > > The OP is not saying that we should go out and advertise that Django > is a great CMS. In fact he spends half of his post making trying to > preemptively shut all the know-it-all folks up before they even start > with, "The problem with your post is... [insert ignoramus disguised as > b-rated philosophy]". > > The fact of the matter is that the best software sometimes comes from > those who have no business sense (or any sense for that matter). > Django's community is very closed minded. For those of you who would > like to promote Django as awesome for building ['CMS', 'SOCIAL > APPLICATION', 'INSERT YOUR FAVORITE WHEEL TO REINVENT'], feel free to > do so. You're helping yourself, not the closed-minded folks. They > don't get jobs usually which is why they work for free. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Selling Django
Richard, Glad I managed to get across where I'm coming from - I was struggling a bit with coming up with how to express it :). Great to hear you're going to contact Tom and Venkatraman about helping. I hope you didn't take anything I said as wanting to pour cold water on where you're coming from - it is an interesting topic and, like I said, I appreciate there are plenty of current and potential users for the re- usable apps in the CMS-type-space out there so anything that can be done to improve those is of course beneficial and would help raise the profile of Django (plus if I do end up doing something more CMS-y in future I'll be delighted if there's some good stuff there :). Regards, Matt On Jun 17, 7:39 pm, Richard Shebora wrote: > Matt, > > Between you and Russ I see what you mean. I will contact Tom and > Venkatraman regarding their concept to see how I can help. I am not > proficient with django's paradigm yet, but I can get better in the > process. > > Thanks, > Richard Shebora > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: how to eliminate duplicates
I'm assuming there's no fields on the duplicate player instances that need merging - from your mention of "shift all records of the duplicate" I'm reading that as "shift all records that relate to the player" - otherwise it will need human intervention. Having stated that assumption, while it's possible someone may have a re-usable bit of code to do the repointing of relationship fields (as I figure it's probably possible to knock something up that looks at the relationship fields/reverse relationships on a given class and do the updates), for a one off like this (and assuming a SQL back-end) if I were faced with that problem I personally would write a script to figure out what Player record IDs are duplicates (iterative over values_list of the id, first_name and last_name, build up map of full name in a canonical form [lower-case the concatenation] to IDs, pick the lowest number from the list for a given name as being the master and treat the rest as the duplicates) and then generate and run the raw sql to update any column in tables that points to the IDs (i.e. UPDATE foo SET blah_id= %s WHERE blah_id IN (3,4,123,4) for foreign key fields and also for m2m tables) and then do the deletions with .delete() calls on the objects. On Jun 18, 2:29 am, Kenneth Gonsalves wrote: > hi > > I have a problem - there is a model called Player with first_name and > last_name. There is a unique_together constraint on first_name and last_name. > However I find that the people doing data entry have been entering things like > Ram Sharan and RAM SHARAN which are two different names. Of course I can > prevent future mistakes by adding validation, but now I am faced with the > problem of merging these records - any suggestions on how to do this? Flow > would be: > 1. select duplicate names > 2. shift all records of the duplicate to the original > 3. delete the duplicate. > -- > Regards > Kenneth Gonsalves > Senior Associate > NRC-FOSS at AU-KBC -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: UnicodeDecodeError (ordinal not in range) when deleting an inline item - 1.2.1
Federico, When trying out what Karen suggests then in the unlikely event that Red Hat doesn't load the environment variables from /etc/apache2/ envvars, one way to find it without consulting documents is to look at the apache start-up script (e.g. /usr/sbin/apache2ctl) so find that on your server and look at what that loads - for example the copy I've got has the following: # the path to the environment variable file test -z "$APACHE_ENVVARS" && APACHE_ENVVARS='/etc/apache2/envvars' # pick up any necessary environment variables if test -f $APACHE_ENVVARS; then . $APACHE_ENVVARS fi Of course as you can see from that it's possible to set an environment variable before running apache2ctl to change the location of envvars, but it's unlikely they'd do that. Matt > > I am not familiar with Red Hat so I can't give you any more specific advice > than that. If it does not use /etc/apache2/envvars (or if you are using some > server other than Apache), then you need to consult the Red Hat doc or > forums to find out how to configure your web server to run with a LANG other > than C or whatever it is currently using. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Forms and non-editable fields
I'm fairly new to django and am just starting to play with it as a framework for web-based applications. The kinds of applications I develop typically have some fields for entities that are non-editable, with some of these being non-editable only some of the time (depending on things like entity state, security level of user viewing the entity), but with those fields being shown still in forms - just not showing a form control, but instead the field value. I also follow a pattern of when a user opens an entity to look at it in "read mode" they're shown basically the same layout of fields as in "edit mode" (with field labels) but the values of the fields are shown instead of form controls. There's not really anything in django that allows for this sort of behaviour out of the box from what I can see... There's a notion of "editable" for the model field, but that causes the field to excluded (by fields_for_model) from a form entirely, and there's no notion of display-value-only behaviour for widgets. To me something along the following lines would be useful: * form fields have an editable attribute that defaults to true * when building a form from a model when a model field has the attribute set to false then it still includes it as a field but sets the editable attribute on the form field it creates to false * could allow for a list of non-editable field names to passed in to the __init__ method of the form to allow for overriding when creating an instance * form widgets can have a render_noneditable method or some other mechanism that allows them to draw their value for display only which BoundField's as_widget method would call - this allows for widgets to control how their value is rendered, for example an email address widget might show itself as a mailto: link * BoundField's as_widget method would change "if not self.form.is_bound" to "if not form.is_bound or not self.field.editable" so as to only pick up the value from the initial data rather than submitted data (as a non-editable field shouldn't have value in submitted data) * non-editable fields wouldn't be processed in the data 'cleaning' as, again, they shouldn't have values in the submitted data This would then allow for fields to be selectively read only and still have their values displayed. I could, of course, have logic in the form templates instead of the above which embed the field as a hidden field, displays the read value, and then further logic in the submit/save handling to ensure a value change isn't hacked in by the user, but widgets being able to represent their value for display-only purposes seemed cleaner :) As I'm new to django I've no idea if it sits well with the thinking behind django's forms (and there may be major pitfalls with the idea), but I thought I'd punt it as an idea in case anyone else thinks it's useful! Regards, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Forms and non-editable fields
> Interestingly, I wanted to write very similar request, but you passed > ahead of me. :) I'm writing form/questionnaire site for our summer > school and I want to be able render filled forms as text, easy readable > and easy printable. So, my needs are pretty close to yours. It struck me as not very DRY (Don't Repeat Yourself) to define two templates to set out the details of a record where the only real difference is that in one the field values are editable and the other they're not (or in some cases where some fields become uneditable and just have their values shown), and it's messy to put the logic into the template to alternatively render the value or the field widget. > My thought was to define two views for each form - one for editing > and one for viewing filled forms. In latter case in constructor I planned > to replace all widgets with some "label" widget, which would render > its value as raw (probably formatted) text. It's a little easier to work with how django currently does things if the whole form is to be shown in read mode rather than just part of it as you can just override the widgets - if you still want some fields to be editable you hit the issue of django's default form save processing/validation expecting that if a field exists on the form then it will have a value submitted! My current approach to do something that works for me without having to change django is a slightly messy mix of a my own ModelForm subclass and my own template tags that get passed the field so the template tag is what renders the field either as a widget or just as a display value as appropriate. Obviously I'd prefer something like I outlined in my previous post! Regards, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Getting at order_by column values easily in queryset-refactor?
In my application I have a component for displaying paged sorted
tables of objects. Sometimes it's relevant for a column to show
information from a related object. In some cases it's relevant for the
column to show information from related objects where the related
objects are related via a many to many. That's easy enough to do. It's
desirable to be able to sort on such columns. When not sorting on that
column the column will show the names of all the related objects for
the given row. When sorting on that column it's desirable to show the
name of the related object that sorts to that position.
So if you have Contract A and Contract B with Contract A linking to
Supplier 2 and Contract B linking to Supplier 1 and Supplier 3 the
desired results to display (when sorting by supplier) would be:
Contract B | Supplier 1
Contract A | Supplier 2
Contract B | Supplier 3
(when sorting on contract name you'd just see one row for Contract B
Now with queryset_refactor I can order by the supplier names no
trouble, and I get the correct ordering of contracts in the queryset,
but I don't think there's a clean way for me to get at the values from
the order_by when using a queryset returning objects without using
extras() to do the order_by and include it as a select extra (or use
extras() to just specify the select using the sql table name under the
assumption that it will be added in to fulfill the order_by).
Possible extra features in QuerySet that could provide me with a
tidier way of getting at it would be to allow the "select" part of
extras to specify supplier__name style references as well as just raw
SQL, or to just allow the "select" part of extras to specify a
supplier__name reference if it's in the order_by too then you get that
order_by back. An alternative is some way of saying "I want you to add
an attribute called order_bys to the objects in the returned set which
contain the order_by values". So then on each object from the queryset
I'd have .order_bys which would be, say, {'suppliers_name':'Supplier
1'}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Getting at order_by column values easily in queryset-refactor?
> Having read this again in light of your complaint in #6701, I should > point out that it's not going to work like this if you're always > filtering on Contract. Not really a complaint in #6701 - you didn't say at first that you were going to remove support for m2m order_by, so I was concerned that in the future people would do m2m order_bys and then hit the issue that .count() wouldn't match len(queryset). My apologies for the drift into discussing the meaning of m2m order_by though - I just replied there 'cos that's where you said up that you didn't think it made sense for django to do m2m order_by. > A queryset is going to return one object for each > distinct object if you do the equivalent of Contract.objects.all(), not > on per many-to-many result. So the .distinct() method is going to become redundant in qf-rf because it will effectively always be the case? > So if you want to order by suppliers like this, you'll need to do a > queryset based on suppliers and pull back their related contract objects > and then you can order on suppliers however you like. So in the future with qs-rf I won't even be able to achieve this using on a query of contracts by using .extras() to join in the suppliers table for the purposes of expanding/sorting the results? Contract objects are the focus of the results I want, and it's a queryset of these that I pass to the paginator. Constructing something to pass to the paginator from the starting point of supplier objects just seems horribly inefficient and requires a chunk of special case code for that specific sort rather than the alternative of a tweak to expand the initial result set. If django isn't going to have the notion of ordering on an m2m field and .extras() can't be used to work around this then I think I'll just subclass queryset instead to make it do what I want. Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Getting at order_by column values easily in queryset-refactor?
> It's more than a preference and it's very important to realise that. It > is not possible for it to work unless you pick a behaviour arbitrarily. > Suppose you have the following objects: I don't think I've ever said anything about preferences (apologies if I had). It is, IMHO, a design choice as to whether to support something in an API or not. If the semantics of an operation could have several interpretations no clear correct one then it's a design choices as to whether to support that operation or not, and then if deciding to support it which interpretation to go for (with many external and internal factors feeding into that decision). I'm certainly not trying to suggest there's anything wrong with your design choices, I'm just trying to say where I'm coming from and find out where you're coming from! > > A : related to x1, x2, x3 > B : related to x1 and x3 > C : related to nothing. > > One possible "ordering" on the related m2m field here is C, B, A: using > a "result set size" ordering. Two others are "C, A, B" and "A, B, C", > using lexicographic ordering, after ordering the m2m set and with two > alternatives because there are two possibilities for how to order the > empty set. Another possibility is "A, B, C" based on doing it all in one > SQL query and picking the first row (so only the first many-to-many > result will have an effect) and where "A" happens to sort before "B" for > some reason. You happen to want A, B, A, A, B with C either first or > last (plus a couple of permutations depending upon how A and B order > themselves). > > All of these orderings are possible, although your one is probably the > least logical on the grounds that it changes the result set. The problem > is that none of them are particularly canonically correct. I've never commented on how logical my one is - just that it would be the most useful to me and I've given an example of why/what I'd use the behaviour for. The example I've given of how the data would be presented to the user when they request sorting a data table on such a multi value column is a pattern I became familiar with many years ago doing Lotus Notes development work and has been useful as a way of presenting data to users in the applications I've developed over the years in other platforms. I think of the ordering behaviour I'm after as being like a SQL join. In your example above you'd apply all the filtering to give your final set of primary objects and then because sorting is wanted on an attribute of the other class of objects you get the tuples (A,x1),(A,x2),(A,x3),(B,x1),(B,x2),(C,NULL) and you'd then sort those tuples. Regarding none of them being particularly canonically correct surely just means that there's no clear choice, not that none of them could ever be chosen (no clear choice unless other factors from an outside context come into play, for example, a common design pattern emerged in a large number of django applications that would find one of the orderings more useful than the others - in that case it may be the "arbitrary" choice is then to implement that and document that as the behaviour so as to serve the needs of that user base unless there are still compelling reasons not to). > > > > A queryset is going to return one object for each > > > distinct object if you do the equivalent of Contract.objects.all(), not > > > on per many-to-many result. > > > So the .distinct() method is going to become redundant in qf-rf > > because it will effectively always be the case? > > Not at all. I explicitly said the all() query, which is essentially what > you are doing. It's impossible to automatically tell if distinct() will > be wanted/needed or not, so it cannot be removed for the general > filtering case. There are still going to be cases when a query returns > multiple results unless you use distinct(). However, adjusting the > order_by() fragment will not be any of those. It only orders the result > set (at the SQL level), it does not change the result set. Probably my inexperience with django - but I wasn't sure if you meant "any query that starts from .all()" by that which is why I asked. > Queyrset-refactor doesn't introduce new magical powers to querysets. > They will still behave basically the way they did before, only with less > bugs. Your current attempt to order by a many-to-many happened to work > by accident, mostly because I didn't insert all the extra overhead to do > that checking (constructing a query is expensive enough as it is) and I > expected most people would work out that it isn't a well-defined > operation. I do appreciate the effort you're putting into queryset-refactor - I'm just trying to understand what may or may not be possible with it in this area, and now I know, so that's good! I'm not asking for it to support my behaviour, and I've certainly not suggested it should have magical powers. > accessing a many-to-many relation. I suggested one approach to solving > this, w
Quick question about qs-rf and queries using distinct and order_by on foreign key fields
I see that in the latest svn checkout of qs-rf if you have a query set which has had distinct() called and then order_by() on a foreign key field you don't get the ordering on that foreign key field - the resulting generated sql query has the joins for the foreign table ready to be used for the order_by, but the "if not distinct or elt in select_aliases" bit inside get_ordering() prevents the actual ORDER BY portion being added. I was just wondering if that's a temporary thing due to that section of code being work in progress, or whether it will be the case now that you can't use distinct with order_by on foreign key fields. Thanks, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Quick question about qs-rf and queries using distinct and order_by on foreign key fields
> There's nothing in the queryset-refactor branch that's really "work in > progress" any longer (at least not committed to the tree). So please > open a ticket with a short example so that this doesn't get forgotten. Thanks Malcolm - I've opened a ticket for it now (number #7070). Regards, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Queryset-refactor branch has been merged into trunk
On Apr 27, 4:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I merged queryset-refactor into trunk just now. This was changeset > r7477. Thanks for all your hard work Malcolm on queryset-refactor, it's much appreciated! Regards, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: urls.py and adding an OR to the regexp
On May 28, 8:53 am, Thierry <[EMAIL PROTECTED]> wrote: > Hello django users, > > I'm new to django, and I was looking to implement a very simple url > scheme that I used for a PHP site. > It's simply an OR done into the matching. Taking the simpliest, I > would like to implement this regexp: > ^pric(e|es)/ > into urls.py, but the () are overlapping with the text capture, as it > seems. If you want to use parentheses that don't capture use "?:" to flag it as non-grouping. So instead try: ^pric(?:e|es)/ Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: urls.py and adding an OR to the regexp
On May 28, 2:06 pm, [EMAIL PROTECTED] wrote: > Couldn't you also use something along the lines of > ^price[s]/ > > Though I may have the syntax wrong. Just to correct your syntax the regular expression for making the last letter in that example optional would be: ^prices?/ Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
