Re: Digest for django-users@googlegroups.com - 18 updates in 11 topics

[郁夫]

急
On Oct 17, 2014 9:19 PM,  wrote:

> django-users@googlegroups.com
> 
>   Google
> Groups
> 
> 
>   Topic digest
>  View all topics
> 
>
>-  making an http request internally <#1491e42fd01f080a_group_thread_0>
>- 3 Updates
>-  django.views.decorators.http.condition decorator
><#1491e42fd01f080a_group_thread_1> - 2 Updates
>-  Solved: save as new in the Admin with 1:1 inlines causes
>IntegrityError <#1491e42fd01f080a_group_thread_2> - 1 Update
>-  OSQA multi language tutorial <#1491e42fd01f080a_group_thread_3> - 1
>Update
>-  Django 1.7, KeyError: u'manager' error
><#1491e42fd01f080a_group_thread_4> - 2 Updates
>-  Upgrading Django (to 1.7) <#1491e42fd01f080a_group_thread_5> - 1
>Update
>-  how to use __init__ in a form (passing an extra variable to the
>form) <#1491e42fd01f080a_group_thread_6> - 1 Update
>-  Unable to store static <#1491e42fd01f080a_group_thread_7> - 2
>Updates
>-  How to "automatically " populate "last_updated_by" DB columns with
>the current user's id <#1491e42fd01f080a_group_thread_8> - 1 Update
>-  How do I create a simple user view web page to create/add mysql db
>entries? <#1491e42fd01f080a_group_thread_9> - 2 Updates
>-  Porting to Django Linux with SQL Server Backend
><#1491e42fd01f080a_group_thread_10> - 2 Updates
>
>   making an http request internally
> 
>   jus...@fanout.io: Oct 16 09:02PM -0700
>
> Hey list,
>
> I am writing a middleware class that needs to be able to make HTTP
> requests
> to the application as part of it's processing. I'd like to be able to do
> this internal to the Django app if possible, rather than having to make
> external requests to the webserver hosting the Django app.
>
> I've discovered that I can use django.core.urlresolvers.resolve to obtain
> a
> view function for a given URL. Awesome! This gets me /very/ close, but I'm
> missing a couple of things:
>
> 1) If I simply call the view function obtained from resolve(), it will be
> executed without middleware. I still want all the usual middleware
> processing to occur though.
>
> 2) I'm not sure how to create a fresh HttpRequest object to use for an
> internal request, so my code awkwardly modifies the request object it was
> provided in order to use it for a subrequest. That doesn't feel quite
> proper.
>
> Any tips here would be great. Thanks!
>
> Justin
>   Erik Cederstrand : Oct 17 02:11PM +0200
>
> > Den 17/10/2014 kl. 06.02 skrev jus...@fanout.io:
>
> > I am writing a middleware class that needs to be able to make HTTP
> requests to the application as part of it's processing. I'd like to be able
> to do this internal to the Django app if possible, rather than having to
> make external requests to the webserver hosting the Django app.
>
> Maybe you can use the Django test client? I believe it supports the
> functions you need.
> https://docs.djangoproject.com/en/1.7/topics/testing/tools/#the-test-client
>
> Erik
>   Collin Anderson : Oct 17 05:56AM -0700
>
>
> > 1) If I simply call the view function obtained from resolve(), it will
> be
> > executed without middleware. I still want all the usual middleware
> > processing to occur though.
>
> Undocumented, unsupported, but this might work:
> from myproject import wsgi
> response = wsgi.application.get_response(request)
>
> or get a fresh handler (slower):
> from django.core.handlers.wsgi import WSGIHandler
> handler = WSGIHandler()
> response = handler.get_response(request)
>
>
> > internal request, so my code awkwardly modifies the request object it
> was
> > provided in order to use it for a subrequest. That doesn't feel quite
> > proper.
>
> I think deepcopying the request and modifying it makes sense here.
> Otherwise, depending on what you need, you'll need to copy the session and
> csrf cookies, and set up things like request.META['HTTP_HOST'] by hand.
>   Back to top <#1491e42fd01f080a_digest_top>
>   django.views.decorators.http.condition decorator
> 
>   Anton Novosyolov : Oct 16 11:20PM -0700
>
> I have a question about this part:
>
> elif (not if_none_match and request.method == "GET" and res_last_modified
> > and if_modified_since and res_last_modified <= if_modified_since):
> > response = HttpResponseNotModified()
>
>
> If I don't use etag, and request method is HEAD then 200 is returned.
>
> Some sites for checking 304 status (e.g. http://last-modified.com/en/ )
> use
> HEAD for checking.
>   Collin

Re: how to update data in FK fields another Model

[carlos]

+Collin Thank this is working perfects :)

Cheers

On Thu, Oct 16, 2014 at 3:31 PM, Collin Anderson 
wrote:

> Hi,
>
> Would this work?
>
> ModelA.objects.filter(id=self.fk_name_id).update(field_count=F('field_count')
> + 1)
>
> Collin
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/3764cfdf-bc7f-4acf-bcc2-25d250094b7a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAM-7rO1gOvifKDZ1N2ZQVZ9VA-TggMfWssfFnSPAFbaiJCmuaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to deny access to a logged user directly to a specific URL

[Kelvin Wong]

Have you reviewed this?

https://docs.djangoproject.com/en/1.6/ref/contrib/formtools/form-wizard/

K


On Friday, October 17, 2014 10:08:08 AM UTC-7, Martin Torre Castro wrote:
>
> Hello,
>
> at my project we need some sort of system for allowing/denying some access 
> to an URL.
>
> The example, we want to make some kind of wizard. 
>
>
>1. The user inputs the first object at the the first screen (A 
>screen), and then he press "Continue".
>2. Now we get the data and redirect to a second screen (B screen), 
>where we the user should enter a second object.
>3. The wizard goes on...
>
> The problem is that if we do so, the user can write the B url at the 
> browser and access the B screen. The user has made the login, but even so, 
> we don't want him to get there without passing through A screen.
>
> We don't know how to achieve this or look for this in internet. We only 
> know about user session for doing this.
>
> Is there another way? Some help?
>
> Thanks in advance.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2468cedf-36a8-4241-9205-1774a728d7c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File Storage API: save file to DB model and disk: separate disk path from file name

[Jon Dufresne]

On Fri, Oct 17, 2014 at 4:45 PM, Russell Keith-Magee
 wrote:
> Achievable? probably. Easy? No. You're going to be digging in the weeds on
> this one.
>
> If I were trying to do this, I wouldn't try and get this to work with the
> existing FileField - I'd be writing my own Field definition. You can crib
> extensively from the existing definition, but everywhere that the current
> model points at it's own storage to get a filename, you use the foreign key
> to get the full file name.
>
> Essentially, it's going to be a merger of FileField and ForeignKey. I
> haven't done this myself, but my gut tells me this is in the realm of the
> "possible, but complicated".
>
> The other way that might be worth looking into is to follow the lead of
> GenericForeignKey. That's an example of a field that "looks" like a single
> column, but is implemented as two columns under the hood. You'll be looking
> to do a similar thing - write a "wrapper" field that points at the name and
> path fields to produce a composite "full file path" field. That composite
> field will be a lot closer to what FileField is expecting, so it might be a
> little easier to merge *that* with FileField than to merge FileField with
> ForeignKey. Then, you put the composite field on the StoredFile model, and
> traverse down the foreign key relation whenever you need to access the file.

Thanks for the feedback and suggestions.

I'll play around a bit and give it a shot.

My fear with this approach is third party applications with FileFields
will now now handle files differently. Luckily this doesn't affect me
at the moment, but may in the future.

Cheers,
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CADhq2b7r4KOFjizyNimP4x9vzjD%2B%2BS%2Bh_b0jEq91fz_e_D-5-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to "automatically " populate "last_updated_by" DB columns with the current user's id

[Ken Winter]

Thanks again Carl (and others) ~

I agree wıth you that the "DB users" approach seems the most promısıng.  
It's the one I will pursue, and certainly glad to share the code when I 
have some worth sharing - and quite likely I'll have some more questions 
before that, as I try to implement this idea.  

As it happens, I'm leaving on a trip tomorrow, so it may be a while for my 
next communiqué on this matter.  But I'll be back!

~ Ken

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2d560d97-335c-4b3a-99b3-e72818491337%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File Storage API: save file to DB model and disk: separate disk path from file name

[Russell Keith-Magee]

On Sat, Oct 18, 2014 at 3:32 AM, Jon Dufresne 
wrote:

> Hi,
>
> I'm trying to use the File Storage API to create a custom handler for
> files. Here are my goals:
>
> Stored files are represented both in the database and on disk with the
> following model:
>
> class StoredFile(models.Model):
> name = models.CharField(max_length=255)
> path = models.CharField(max_length=255, unique=True)
>
> The "name" attribute represents the filename presented to the user:
> "My document.txt". The path attribute represents the basename as the
> file exists on the disk in MEDIA_ROOT, usually created with mktemp:
> "tmpAsdf123" in "/path/to/media". The goal of this configuration:
>
> 1. Files are stored on disk
> 2. There are no filename collisions (duplicate names can exist but the
> paths will be unique)
> 3. Uploaded files preserve the name exactly, may be downloaded later,
> are never mangled
> 4. All files are stored in an identical manner
>
> You can think of "name" as an abstract user-oriented name, and path as
> the actual on disk representation.
>
> What I want, saving a file should save the file to path and record an
> entry for the StoredFile model. Ideally FileFields would be a FK to
> this model--currently it is a string.
>
> I'm having a little trouble getting started. Some issues:
>
> 1. FileFields store strings, would like it to be a one-to-one FK (or
> an intereger id)
> 2. Most of the storage API takes a single argument "name" Should this
> be the name as stored on disk? The name as presented to the user? The
> PK from the StoredFile model?
>
> Is what I'm trying to do achievable? Am I approaching the problem
> correctly?
>

Achievable? probably. Easy? No. You're going to be digging in the weeds on
this one.

If I were trying to do this, I wouldn't try and get this to work with the
existing FileField - I'd be writing my own Field definition. You can crib
extensively from the existing definition, but everywhere that the current
model points at it's own storage to get a filename, you use the foreign key
to get the full file name.

Essentially, it's going to be a merger of FileField and ForeignKey. I
haven't done this myself, but my gut tells me this is in the realm of the
"possible, but complicated".

The other way that might be worth looking into is to follow the lead of
GenericForeignKey. That's an example of a field that "looks" like a single
column, but is implemented as two columns under the hood. You'll be looking
to do a similar thing - write a "wrapper" field that points at the name and
path fields to produce a composite "full file path" field. That composite
field will be a lot closer to what FileField is expecting, so it might be a
little easier to merge *that* with FileField than to merge FileField with
ForeignKey. Then, you put the composite field on the StoredFile model, and
traverse down the foreign key relation whenever you need to access the file.

Of course YMMV, and if it breaks, you get to keep all the shiny pieces :-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84_QJ7-Y-fjfbvyxbrmn2mdbGqJTii-r%2B51UPxx9N%3Dxw0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to "automatically " populate "last_updated_by" DB columns with the current user's id

[Carl Meyer]

Hi Ken,

On 10/17/2014 05:16 PM, Ken Winter wrote:
> Ken: My idea for doing this goes something like:
> 
>  1. For every session, let's say that the Django app's database
> connection is with a user I'll call "myapp" here.  User "myapp" has
> the CREATEUSER privilege.
>  2. Someone requests a page from the app.  They're not logged in yet, so
> they get the login page.
>  3. The app handles authentication in usual Django fashion. 
>  4. When the user has been authenticated, the app:
>  1. Checks whether a database user already exists named ,
> where  is the user just authenticated by the app, and
> hence is that value that we want to have recorded in the
> last_update_by columns. 
>  2. If not, creates a  user. 
>  3. Issues the SQL command: SET SESSION AUTHORIZATION ''.
>  5. In the database, all user tables have an ON UPDATE trigger that
> assigns the PostgreSQL system variable /current_user
> /to/last_updated_by/ for each row that was updated. 
>  6. Because the SET SESSION AUTHORIZATION command was executed,
> /current_user/ evaluates to  throughout this session. 
> So /last_updated_by/ gets set as required.  An added benefit is that
> the permissions applicable throughout the session are those of
> , and  is an ordinary end user without any admin
> permissions.  So a certain kind of possible destructive mischief or
> bumbling is prevented.
> 
> Ken: Here are the aspects of this scheme that I'm more and less
> confident about:
> 
>  1. I'm fairly confident that steps 1-3 are OK, because I think that's
> normal Django process.
>  2. I'm less confident about step 4, because I'm not very fluent with
> how Django handles actions like this.
>  3. I'm confident that this will work at the DB level, i.e. that steps
> 5-6 will work fine once step 4 has been accomplished.  I'm fluent
> with PostgreSQL, and I've unit-tested these bits.
> 
> Ken: I'd appreciate comments and suggestions about any and all parts of
> this approach.
> 
> Ken: If it /is/ feasible, this does satisfy my criteria of being
> "universal" (all DB updates thru the Django app, whether thru object
> model save() or raw SQL or whatever, would appropriately set
> last_updated_by) and "magic" (once the login process is programmed to do
> step 4, last_updated_by would be properly set without any action of the
> developer who programs each update action).

Yes, I think this approach looks quite feasible, and probably simpler
than I'd first thought to implement, given that you don't need the
database to perform authentication for you and don't mind using a
"master user" and then SET SESSION AUTHORIZATION.

There may be devils in the details I'm not thinking of, but I think step
4 _should_ be relatively straightforward with a custom authentication
backend and some raw SQL via cursor.execute().

If using Django 1.6 or later, you'll want to ensure your CONN_MAX_AGE
(https://docs.djangoproject.com/en/1.6/ref/databases/#connection-management)
is set to 0, to avoid the possibility of database session authorization
leaking from one request to the next via a reused database connection.
Reconnecting on every request imposes some performance penalty, but this
may not be a problem for you (until recently this was a penalty paid by
every Django project that didn't use an external connection pool).

I would definitely pursue this approach over "patch the DB connector and
rewrite SQL". I'd love to see some code if you get it working and can share!

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5441A6C7.6050302%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Russell Keith-Magee]

Hi Anshuman,

Firstly, a question like this is probably better suited to
django-developers - that's the list where we discuss proposed modifications
to Django itself. You're more likely to get the attention you need on that
list.

That said - I'm not sure I see the benefit here. I've left a comment on the
ticket.

Yours
Russ Magee %-)

On Sat, Oct 18, 2014 at 2:12 AM, Anshuman Aggarwal <
anshuman.aggar...@gmail.com> wrote:

> Posting this Django Project ticket that I opened to track the enhancement
> request to update multiple rows with different values for the same field
> for a particular Django queryset in a single SQL query without having to
> write raw SQL.
>
> https://code.djangoproject.com/ticket/23646
>
> A possible SQL solution is outlined here but it should ideally be
> supported via the Django Manager I feel and not via a Raw SQL which becomes
> much harder to maintain.
>
>
> http://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-query-using-postgresql
>
> Thoughts anyone?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/812f359d-13cb-43c1-9515-52632b663911%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84_xh4Dox4uegV%3DoUOFwKK%3D77Nc0MLY9P9z8Nfkr4CcDKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to "automatically " populate "last_updated_by" DB columns with the current user's id

[Ken Winter]

To keep this conversation fairly modular, I'm responding to different 
possible solutions in different posts.  This one is about Carl's comments 
on:

>  2. Have Django create a new *database user *for each session login, 
> using the user id that Django knows and that I want to record in the 
> last_updated_by column, and establish a new database connection with 
> that user as the user. Then the database would know the user and 
> could record it in the last_updated_by column for every update in 
> that session.  At logout, the database user would be dropped.  Do 
> you think a Django app could be programmed to handle the creation 
> and dropping of this user, and to establish a db connection for that 
> user?  I will also put this proposal to a PostgreSQL forum to see if 
> they think it would work on the database end. 

My comments inserted below are prefaced with "Ken:"

On Thursday, October 16, 2014 12:13:20 PM UTC-4, Carl Meyer wrote:

I think this is probably technically possible (though I don't see why 
> you'd drop the database user when they logout, better to keep the 
> account around for their next login). I also expect it will be quite a 
> tough slog, take weeks or more likely months to get working reliably, 
> and require you to become an expert on the internals of the Django ORM. 
> I also think it's the only feasible path to your "universal and magic" 
> goal. 
>
> (Here's a blog post where someone tried this and apparently got it 
> working, though I see at least three things they did along the way that 
> are terrible hacks and either insecure or quite likely to break: 
>
> http://blog.everythingtastesbetterwithchilli.com/2010/02/07/per-user-database-authentication-in-django-/)
>  
>
>

Ken: Thanks for this link.  What the author of that post did is similar to 
what I had in mind, tho my requirement is more modest than his.  He wants 
to have the database actually handle the authentication.  I'm OK having 
Django authenticate its users; I just want to communicate their user-ids to 
the database with each query.

Ken: My idea for doing this goes something like:

   1. For every session, let's say that the Django app's database 
   connection is with a user I'll call "myapp" here.  User "myapp" has the 
   CREATEUSER privilege.
   2. Someone requests a page from the app.  They're not logged in yet, so 
   they get the login page.
   3. The app handles authentication in usual Django fashion.  
   4. When the user has been authenticated, the app: 
   1. Checks whether a database user already exists named , where 
   is the user just authenticated by the app, and hence is that 
  value that we want to have recorded in the last_update_by columns.  
  2. If not, creates a  user.  
  3. Issues the SQL command: SET SESSION AUTHORIZATION ''. 
  5. In the database, all user tables have an ON UPDATE trigger that 
   assigns the PostgreSQL system variable *current_user *to* 
   last_updated_by* for each row that was updated.  
   6. Because the SET SESSION AUTHORIZATION command was executed, 
   *current_user* evaluates to  throughout this session.  So * 
   last_updated_by* gets set as required.  An added benefit is that the 
   permissions applicable throughout the session are those of , and 
is an ordinary end user without any admin permissions.  So a 
   certain kind of possible destructive mischief or bumbling is prevented.

Ken: Here are the aspects of this scheme that I'm more and less confident 
about:

   1. I'm fairly confident that steps 1-3 are OK, because I think that's 
   normal Django process.
   2. I'm less confident about step 4, because I'm not very fluent with how 
   Django handles actions like this.
   3. I'm confident that this will work at the DB level, i.e. that steps 
   5-6 will work fine once step 4 has been accomplished.  I'm fluent with 
   PostgreSQL, and I've unit-tested these bits.
   
Ken: I'd appreciate comments and suggestions about any and all parts of 
this approach.

Ken: If it *is* feasible, this does satisfy my criteria of being 
"universal" (all DB updates thru the Django app, whether thru object model 
save() or raw SQL or whatever, would appropriately set last_updated_by) and 
"magic" (once the login process is programmed to do step 4, last_updated_by 
would be properly set without any action of the developer who programs each 
update action).

Ken: Thanks again!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6ccce391-951f-45c4-808b-ba11c9f6975a%40googlegroups.com.
For more options, visit https://grou

File Storage API: save file to DB model and disk: separate disk path from file name

[Jon Dufresne]

Hi,

I'm trying to use the File Storage API to create a custom handler for
files. Here are my goals:

Stored files are represented both in the database and on disk with the
following model:

class StoredFile(models.Model):
name = models.CharField(max_length=255)
path = models.CharField(max_length=255, unique=True)

The "name" attribute represents the filename presented to the user:
"My document.txt". The path attribute represents the basename as the
file exists on the disk in MEDIA_ROOT, usually created with mktemp:
"tmpAsdf123" in "/path/to/media". The goal of this configuration:

1. Files are stored on disk
2. There are no filename collisions (duplicate names can exist but the
paths will be unique)
3. Uploaded files preserve the name exactly, may be downloaded later,
are never mangled
4. All files are stored in an identical manner

You can think of "name" as an abstract user-oriented name, and path as
the actual on disk representation.

What I want, saving a file should save the file to path and record an
entry for the StoredFile model. Ideally FileFields would be a FK to
this model--currently it is a string.

I'm having a little trouble getting started. Some issues:

1. FileFields store strings, would like it to be a one-to-one FK (or
an intereger id)
2. Most of the storage API takes a single argument "name" Should this
be the name as stored on disk? The name as presented to the user? The
PK from the StoredFile model?

Is what I'm trying to do achievable? Am I approaching the problem correctly?

This design was taken from an existing application, so
interoperability is also a goal.

Cheers,
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CADhq2b6aCJ3H%2BWA%2BLL7XNo7AxN5XWGNJG_ruRELRs-eY6cWpNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to "automatically " populate "last_updated_by" DB columns with the current user's id

[Carl Meyer]

Hi Ken,

On 10/17/2014 01:09 PM, Ken Winter wrote:
> On Thursday, October 16, 2014 12:13:20 PM UTC-4, Carl Meyer wrote:
> 
> I don't see any way this is feasible, if you want it to cover raw SQL
> executed through ``cursor.execute``. Are you planning to parse the SQL
> for every raw statement, 
> 
> /Ken: Yes./
> 
> figure out if its an INSERT or UPDATE, 
> 
> /Ken: Yes./
> 
> and then
> figure out which row(s) it might affect? 
> 
> Ken: No; at this point my code inserts an element that assigns the user
> id to "last_updated_by" into the SET clause of an UPDATE query or the
> VALUES clause of an INSERT query, then hands the modified query back to
> the connector, which passes it on to the DB.
> 
> At this point you're well into
> re-implementing chunks of PostgreSQL in your app code.
> 
> 
> Ken: No, just a modest bit of parsing and tweaking of SQL queries.  My
> code doesn't have to execute the queries in any way.

I admire your intrepidity!

But on a project I'm responsible for, I'd never let this pass code
review. SQL is a complex language; are you using a battle-tested SQL
parser that you are confident handles every possible syntax variation
correctly? Or are you hand-rolling a regex-based "parser" that will work
correctly for the simplest queries, but break when it encounters
anything you didn't anticipate?

To name a few examples selected randomly from a brief perusal of the
Postgres docs:

- Does your code handle an INSERT with DEFAULT VALUES but no VALUES clause?

- Does your code handle an UPDATE that touches multiple tables using a
FROM clause?

- Does your code handle writable CTEs?

You may say "I just won't use any of those SQL features"; at that point
you don't have a solution that is safe to hide from your developers, and
you may as well .

> Ken: So to implement this in Django, one would have to find the Django
> counterpart of ZPsycopgDA.db.py and insert this code in the same way.

Yes, you'll have to do this either by patching Django, or monkeypatching
it at runtime. I think you'll be happier in the long run if you avoid
doing either of those things.

You'll also have to install a "current user ID" threadlocal for this to
work, which introduces another way in which this solution won't really
be transparent to your developers - they'll have to always make sure
they install a threadlocal user ID before doing anything with the
database. And if they install the wrong one, rather than being a clear
local bugfix (as in the case of passing the wrong user to model.save()),
it's a much more mysterious action-at-a-distance bug to track down.

And, lastly, this solution still isn't really "universal" because it
won't help if someone connects to the database directly instead of
through your app.

> Ken: Whaddya think?

I think that you can almost certainly get this working for simple cases,
and it might even be a fun exercise, but if it were my production
project that I needed to maintain for the next several years, I wouldn't
touch this solution with a ten-foot pole.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54417535.3000800%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: How to "automatically " populate "last_updated_by" DB columns with the current user's id

[Ken Winter]

To keep this conversation fairly modular, I'm responding to different 
possible solutions in different posts.  This one is about Carl's comments 
on:

>  1. Stick some code into the database connector, as I described in 
> possibility 1 of my original post.  I guess the connector would be 
> the "connection" class? 

My commenst inserted below are prefaced with "Ken:"

On Thursday, October 16, 2014 12:13:20 PM UTC-4, Carl Meyer wrote:


> I don't see any way this is feasible, if you want it to cover raw SQL 
> executed through ``cursor.execute``. Are you planning to parse the SQL 
> for every raw statement, 


*Ken: Yes.*
 

> figure out if its an INSERT or UPDATE, 


*Ken: Yes.*
 

> and then 
> figure out which row(s) it might affect? 


Ken: No; at this point my code inserts an element that assigns the user id 
to "last_updated_by" into the SET clause of an UPDATE query or the VALUES 
clause of an INSERT query, then hands the modified query back to the 
connector, which passes it on to the DB.

At this point you're well into 
re-implementing chunks of PostgreSQL in your app code. 


Ken: No, just a modest bit of parsing and tweaking of SQL queries.  My code 
doesn't have to execute the queries in any way.

Ken: Here's how I did it back in the dark ages, when Zope rather than 
Django was my framework: 
https://drive.google.com/file/d/0B-thboqjuKZTNG9DR3lqalJaOWM/view?usp=sharing.  
The db.py module is the query pathway of the ZPsycopgDA adapter.  I have 
changed this out-of-the-box Zope module only by adding the lines I have 
enclosed here in "ADDED: << ... >>" delimiters.  I have added the whole 
_insert_when_who_updates() function, three lines invoking it from the 
query() function, and a few import lines.

Ken: So to implement this in Django, one would have to find the Django 
counterpart of ZPsycopgDA.db.py and insert this code in the same way.

Ken: Whaddya think?


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b68fba53-11be-47e1-b02f-7740c1647f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Anshuman Aggarwal]

Posting this Django Project ticket that I opened to track the enhancement 
request to update multiple rows with different values for the same field 
for a particular Django queryset in a single SQL query without having to 
write raw SQL. 

https://code.djangoproject.com/ticket/23646

A possible SQL solution is outlined here but it should ideally be supported 
via the Django Manager I feel and not via a Raw SQL which becomes much 
harder to maintain.

http://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-query-using-postgresql

Thoughts anyone?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/812f359d-13cb-43c1-9515-52632b663911%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to deny access to a logged user directly to a specific URL

[Carl Meyer]

Hello Martin,

On 10/17/2014 11:08 AM, Martin Torre Castro wrote:
> at my project we need some sort of system for allowing/denying some
> access to an URL.
> 
> The example, we want to make some kind of wizard. 
> 
>  1. The user inputs the first object at the the first screen (A screen),
> and then he press "Continue".
>  2. Now we get the data and redirect to a second screen (B screen),
> where we the user should enter a second object.
>  3. The wizard goes on...
> 
> The problem is that if we do so, the user can write the B url at the
> browser and access the B screen. The user has made the login, but even
> so, we don't want him to get there without passing through A screen.
> 
> We don't know how to achieve this or look for this in internet. We only
> know about user session for doing this.
> 
> Is there another way? Some help?

I'm not sure that this fits into a generalized "system." Sounds to me
like the view for screen B just needs to check its preconditions
(whatever the result of screen A should be, in the database or session
or wherever), and take appropriate action if the preconditions aren't
met. That action could be displaying an error or redirecting to screen A.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54415E31.1060805%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

How to deny access to a logged user directly to a specific URL

[Martin Torre Castro]

Hello,

at my project we need some sort of system for allowing/denying some access 
to an URL.

The example, we want to make some kind of wizard. 


   1. The user inputs the first object at the the first screen (A screen), 
   and then he press "Continue".
   2. Now we get the data and redirect to a second screen (B screen), where 
   we the user should enter a second object.
   3. The wizard goes on...

The problem is that if we do so, the user can write the B url at the 
browser and access the B screen. The user has made the login, but even so, 
we don't want him to get there without passing through A screen.

We don't know how to achieve this or look for this in internet. We only 
know about user session for doing this.

Is there another way? Some help?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b374d3d6-c485-4388-91ed-3d128ba51b72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to display BST (British Summer Time)?

[Daniel Grace]

I installed pytz and this problem went away.
Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/61323ec4-f798-4c9c-a0c3-003220eec76a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to use __init__ in a form (passing an extra variable to the form)

[Carl Meyer]

On 10/17/2014 01:36 AM, dk wrote:
> took me a little bit to get the self.fields,  since I was trying to
> override directly  as ratiooo.choices.

Yeah, metaclasses are confusing :-)

> and I move the django.setup()  to the top of the file after the imports
> (meantime). not sure what it does, I know that just need to be call
> before any query if not they don't work =(

It sets up the model system (among other things). And yes, it needs to
be called before any database queries occur. But usually you wouldn't
call it in every module that does database queries (though I think you
_can_, it should be idempotent so calling it multiple times doesn't
hurt), usually you would just ensure that it's called once by whatever
script starts up your process. "manage.py" and "wsgi.py" both do this,
so I'm not sure how you're running your Django code that doesn't call
it. If you've got your own startup script of some kind, you should add
django.setup() to it.

> classFormDishes(forms.Form):
> your_email =forms.EmailField(initial="a...@b.com ")
> ratiooo
> =forms.ChoiceField(choices="",widget=forms.RadioSelect(),initial=1)
> def__init__(self,*args,**kwargs):
> self.restaurant_id =kwargs.pop("restaurant_id")
> super(FormDishes,self).__init__(*args,**kwargs)
> self.options =self.make_choices()
> self.fields["ratiooo"].choices=self.options
> 
> defmake_choices(self):
> all =Dish.objects.filter(restaurant_id=self.restaurant_id)
> options_ratio =[]
> fori inall:
> options_ratio.append((i.id,i.name))
> returnoptions_ratio

Looks good!

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54413A21.2090008%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: How to display BST (British Summer Time)?

[Tom Evans]

On Fri, Oct 17, 2014 at 4:14 PM, Daniel Grace  wrote:
> Hi,
> I have the time zone set as follows:
> TIME_ZONE='Europe/London'
> USE_TZ = True
>
> This is the same as GMT.  But what I want is BST (British Summer Time) for
> display purposes, which is UTC + 1 for the "summer" and UTC for the rest of
> the year.
>
> How do I convert to this the value in my templates?
>
> Thanks.
>

'Europe/London' should contain DST transition information, if it is
present in the zone files. So the first question is, where is your
tzdata coming from?

If you have not installed pytz as recommended by the docs, you are
relying on your database and OS to get things right.

For me, with pytz installed, 'Europe/London' has DST info:

>>> import pytz
>>> dt = pytz.timezone('Europe/London')
>>> pprint(dt._utc_transition_times)
[datetime.datetime(1, 1, 1, 0, 0),
 datetime.datetime(1901, 12, 13, 20, 45, 52),
 datetime.datetime(1916, 5, 21, 2, 0),
 datetime.datetime(1916, 10, 1, 2, 0),
 datetime.datetime(1917, 4, 8, 2, 0),

 datetime.datetime(2036, 10, 26, 1, 0),
 datetime.datetime(2037, 3, 29, 1, 0),
 datetime.datetime(2037, 10, 25, 1, 0)]

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1JUpWkf0SnauoPq1c_OxMHQd4bnB7vmBXX5mJ6%2BDq3uMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to display BST (British Summer Time)?

[Daniel Grace]

The date function can only display the offset, it does not actually add the 
offset to the date time.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0f7fbc5c-83a2-4a7d-86a1-705dad309bc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to display BST (British Summer Time)?

[Carl Meyer]

Hi Daniel,

On 10/17/2014 09:14 AM, Daniel Grace wrote:
> I have the time zone set as follows:
> TIME_ZONE='Europe/London'
> USE_TZ = True
> 
> This is the same as GMT.  But what I want is BST (British Summer Time)
> for display purposes, which is UTC + 1 for the "summer" and UTC for the
> rest of the year.

According to
http://en.wikipedia.org/wiki/List_of_tz_database_time_zones, the
Europe/London timezone _is_ UTC+1 for the summer and UTC the rest of the
year. So it seems like there may not be anything you need to do.

> How do I convert to this the value in my templates?

If you want all datetimes displayed in a different timezone than your
TIME_ZONE setting (which really only makes sense if you track each
user's timezone and set the active timezone per-request based on the
user - otherwise just set TIME_ZONE to the one you want to use), you use
timezone.activate():
https://docs.djangoproject.com/en/1.7/topics/i18n/timezones/#selecting-the-current-time-zone

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5441381A.4090403%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: How to display BST (British Summer Time)?

[Kelvin Wong]

https://docs.djangoproject.com/en/1.6/ref/templates/builtins/#date

K



On Friday, October 17, 2014 8:14:12 AM UTC-7, Daniel Grace wrote:
>
> Hi,
> I have the time zone set as follows:
> TIME_ZONE='Europe/London'
> USE_TZ = True
>
> This is the same as GMT.  But what I want is BST (British Summer Time) for 
> display purposes, which is UTC + 1 for the "summer" and UTC for the rest of 
> the year.
>
> How do I convert to this the value in my templates?
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0591c36f-288a-49f5-96f5-5c7f12491df2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to display BST (British Summer Time)?

[Daniel Grace]

Hi,
I have the time zone set as follows:
TIME_ZONE='Europe/London'
USE_TZ = True

This is the same as GMT.  But what I want is BST (British Summer Time) for 
display purposes, which is UTC + 1 for the "summer" and UTC for the rest of 
the year.

How do I convert to this the value in my templates?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3437a26b-5332-440d-88a8-f98ffb500122%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: making an http request internally

[Collin Anderson]

>
> 1) If I simply call the view function obtained from resolve(), it will be 
> executed without middleware. I still want all the usual middleware 
> processing to occur though.
>
Undocumented, unsupported, but this might work:
from myproject import wsgi
response = wsgi.application.get_response(request)

or get a fresh handler (slower):
from django.core.handlers.wsgi import WSGIHandler
handler = WSGIHandler()
response = handler.get_response(request)
 

> 2) I'm not sure how to create a fresh HttpRequest object to use for an 
> internal request, so my code awkwardly modifies the request object it was 
> provided in order to use it for a subrequest. That doesn't feel quite 
> proper.
>
 I think deepcopying the request and modifying it makes sense here. 
Otherwise, depending on what you need, you'll need to copy the session and 
csrf cookies, and set up things like request.META['HTTP_HOST'] by hand.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/206019dc-2ad3-468a-96ec-bd2cba2bb80e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.views.decorators.http.condition decorator

[Collin Anderson]

I'm not an http caching expert, but what you say seems right. Want to open 
a ticket?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4cdb7d88-e439-4f42-9520-2f8a6b47d0ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Solved: save as new in the Admin with 1:1 inlines causes IntegrityError

[Mike Dewhirst]

I discovered a unicode problem related to the degree symbol (°) when 
running under Python 2.7 and dealt with that. It somehow fixed the 
IntegrityError.


One of those things I guess

AWTEW

Mike

On 15/10/2014 9:40 AM, Mike Dewhirst wrote:

Using Django 1.6.7, in the Admin if I change the name of an object (in
this case "substance") with 1:1 relationships and click [Save as new] I
get an integrity error[1]. This was working in Django 1.5.x.

Before I put in the effort to roll back to 1.5 for proof I thought I'd
check the docs and found this with a "Changed in Django 1.6" note ...

https://docs.djangoproject.com/en/1.6/ref/models/instances/#how-django-knows-to-update-vs-insert


Does anyone have a suggestion?

The interactive traceback indicates my save() method on one of the 1:1
models (in this case "gas") is triggering the problem. See below.

Thanks for any pointers

Mike

- - - - - - - - - - - -



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54410C83.7000201%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

OSQA multi language tutorial

[Pavel Vanchugov]

Helloevryone. Is there more detailed documentation for achieving multi 
language site on django? I don't even know what this is 
https://docs.djangoproject.com/en/1.4/topics/i18n/ All i can see is that 
django can "multi language" and that's it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f4d6495a-d7d1-4fc9-ab29-263552588a58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: making an http request internally

[Erik Cederstrand]

> Den 17/10/2014 kl. 06.02 skrev jus...@fanout.io:
> 
> I am writing a middleware class that needs to be able to make HTTP requests 
> to the application as part of it's processing. I'd like to be able to do this 
> internal to the Django app if possible, rather than having to make external 
> requests to the webserver hosting the Django app.

Maybe you can use the Django test client? I believe it supports the functions 
you need. 
https://docs.djangoproject.com/en/1.7/topics/testing/tools/#the-test-client

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/07012208-85FF-4D87-9B35-84E5BEE226B7%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7, KeyError: u'manager' error

[Sanjay Bhangar]

On Fri, Oct 17, 2014 at 2:53 PM, Taenyon Kim  wrote:

> Example
>
> class ModelA(models.Model):
> fielda = models.CharField(max_length=10)
>
> class ModelB(models.Model):
> modela = models.ForeignKey(ModelA)
> fieldb = models.CharField(max_length=10)
>
>
> When I query like "modela_instance.modelb_set()", then I will get
> KeyError: u'manager' as shown below:
>

AFAIK, you want something like "modela_instance.modelb_set.all()" - just
modela_instance.modelb_set() is the manager instance that you call call
methods on (like 'all', 'filter', etc.), but calling the manager directly
doesn't quite work, as you found out :)

All the best,
Sanjay

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAG3W7ZEsi_7iYJP8k2s7ADjZt%2BtCXD2Mkatvrjx1_D%3Do5v%3D%3D_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.7, KeyError: u'manager' error

[Taenyon Kim]

Example

class ModelA(models.Model):
fielda = models.CharField(max_length=10)

class ModelB(models.Model):
modela = models.ForeignKey(ModelA)
fieldb = models.CharField(max_length=10)


When I query like "modela_instance.modelb_set()", then I will get KeyError: 
u'manager' as shown below:



How can I solve this problem?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ff51d5e6-cd7a-4f25-9a45-fce3639962d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django.views.decorators.http.condition decorator

[Anton Novosyolov]

I have a question about this part:

elif (not if_none_match and request.method == "GET" and res_last_modified 
> and if_modified_since and res_last_modified <= if_modified_since): 
> response = HttpResponseNotModified()


If I don't use etag, and request method is HEAD then 200 is returned.

Some sites for checking 304 status (e.g. http://last-modified.com/en/ ) use 
HEAD for checking.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8161a375-d0aa-4c1d-9370-f7aa4d4a7c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

making an http request internally

[justin]

Hey list,

I am writing a middleware class that needs to be able to make HTTP requests 
to the application as part of it's processing. I'd like to be able to do 
this internal to the Django app if possible, rather than having to make 
external requests to the webserver hosting the Django app.

I've discovered that I can use django.core.urlresolvers.resolve to obtain a 
view function for a given URL. Awesome! This gets me /very/ close, but I'm 
missing a couple of things:

1) If I simply call the view function obtained from resolve(), it will be 
executed without middleware. I still want all the usual middleware 
processing to occur though.

2) I'm not sure how to create a fresh HttpRequest object to use for an 
internal request, so my code awkwardly modifies the request object it was 
provided in order to use it for a subrequest. That doesn't feel quite 
proper.

Any tips here would be great. Thanks!

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4030cd9b-03f9-4274-9183-77a2459ff1ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Fred Stluka]

Sounds good!  Thanks!

--Fred

Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

On 10/15/14 8:17 PM, Andrew Pinkham wrote:

Hi,
Thanks to feedback from Fred and a few others, I've started editing Part III to 
make it more accessible.

Part IV was originally set to be published today. Unfortunately, it is not 
ready to be published.

As soon as the new Part III and Part IV are available, I will let you know.

Thanks,
Andrew



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5440CDDD.6030307%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to use __init__ in a form (passing an extra variable to the form)

[dk]

thanks Carl, that  was extremely clear, step by step.

took me a little bit to get the self.fields,  since I was trying to 
override directly  as ratiooo.choices.
and I move the django.setup()  to the top of the file after the imports 
(meantime). not sure what it does, I know that just need to be call before 
any query if not they don't work =(


class FormDishes(forms.Form):
your_email = forms.EmailField(initial="a...@b.com")
ratiooo = forms.ChoiceField(choices="", widget=forms.RadioSelect(), 
initial=1)
def __init__(self, *args, **kwargs):
self.restaurant_id = kwargs.pop("restaurant_id")
super(FormDishes, self).__init__(*args, **kwargs)
self.options = self.make_choices()
self.fields["ratiooo"].choices=self.options

def make_choices(self):
all = Dish.objects.filter(restaurant_id=self.restaurant_id)
options_ratio = []
for i in all:
options_ratio.append((i.id, i.name))
return options_ratio

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/816954de-4e6f-411b-bafc-701a8a708227%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.