Re: UnicodeDecodeError (ordinal not in range) when deleting an inline item - 1.2.1

[Matt Hoskins]

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.

Re: how to eliminate duplicates

[Matt Hoskins]

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: Selling Django

[Matt Hoskins]

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: Selling Django

[Matt Hoskins]

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

[Matt Hoskins]

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

[Matt Hoskins]

> 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: how to use render_to_response, ajax and javascript variables

[Matt Hoskins]

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: how to use render_to_response, ajax and javascript variables

[Matt Hoskins]

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

[Matt Hoskins]

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: mod_wsgi sometimes gives error on first reload but not thereafter

[Matt Hoskins]

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

[Matt Hoskins]

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: UnicodeDecodeError (ordinal not in range) when deleting an inline item - 1.2.1

[Matt Hoskins]

>   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: HttpRequest.DELETE implemented?

[Matt Hoskins]

>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: problem with encoding "utf-8", postgresql 8.3

[Matt Hoskins]

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: pg_get_serial_sequence("unknown", "unknown") - revision 13336

[Matt Hoskins]

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: pg_get_serial_sequence("unknown", "unknown") - revision 13336

[Matt Hoskins]

... 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

[Matt Hoskins]

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=1000463_id=1000151=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.

Subselect in query set .extra(tables=...)

[Matt Hoskins]

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!)

[Matt Hoskins]

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
-~--~~~~--~~--~--~---

GenericRelation setting and behaviour due to .clear() from __set__ in ReverseGenericRelatedObjectsDescriptor

[Matt Hoskins]

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
-~--~~~~--~~--~--~---

Re: urls.py and adding an OR to the regexp

[Matt Hoskins]

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
-~--~~~~--~~--~--~---

Re: urls.py and adding an OR to the regexp

[Matt Hoskins]

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: Queryset-refactor branch has been merged into trunk

[Matt Hoskins]

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: Quick question about qs-rf and queries using distinct and order_by on foreign key fields

[Matt Hoskins]

> 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
-~--~~~~--~~--~--~---

Quick question about qs-rf and queries using distinct and order_by on foreign key fields

[Matt Hoskins]

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: Getting at order_by column values easily in queryset-refactor?

[Matt Hoskins]

> 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, 

Re: Getting at order_by column values easily in queryset-refactor?

[Matt Hoskins]

> 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
-~--~~~~--~~--~--~---

Getting at order_by column values easily in queryset-refactor?

[Matt Hoskins]

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: Forms and non-editable fields

[Matt Hoskins]

> 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
-~--~~~~--~~--~--~---

Forms and non-editable fields

[Matt Hoskins]

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
-~--~~~~--~~--~--~---