Re: Using the Django ORM in a long-running worker process

[Mike Dewhirst]

We saw a presentation last weekend at pyconau by Andrew Godwin about Django 
Channels and you might like to check the YouTube video. It lets long-running 
processes keep web sockets open in parallel with http requests.

Connected by Motorola

Daniel Tao  wrote:

>Thank you for the thorough response, which has proven very helpful, mainly by 
>reinforcing what I was growing to suspect: we've updated the code in our 
>worker processes to close the DB connection after every message, and sure 
>enough we've seen a huge improvement in the form of significantly fewer open 
>DB connections at any given time (where things stood, we were coming 
>dangerously close to hitting the limit set by RDS).
>
>
>To clarify: these aren't really "jobs" as you probably mean. We are very 
>familiar with celery; in fact we use it in our product for background tasks! 
>The worker processes I'm talking about do not receive jobs to execute, they 
>process raw messages in very high volume and are more purpose-built to handle 
>them in a specific way.
>
>
>But that isn't really important or interesting to a general audience. Really I 
>just wanted to say thanks for the tip—it definitely nudged us in the right 
>direction.
>
>On Wednesday, August 17, 2016 at 1:49:22 AM UTC-5, James Schneider wrote:
>
>
>> My team has built a service comprising 3 main parts, a web application and 2 
>> long-running worker processes that process events from a message exchange. 
>> All of these components interact with the same database and use the same 
>> underlying Django "app" for ORM models (i.e. the 2 worker processes call 
>> django.setup() on initialization).
>>
>
>Are the two long term worker instances Django processes, or some other 
>process? If they are Django workers, you're probably not handling jobs 
>correctly.
>
>> We've had some issues with the worker processes failing to recover in the 
>> face of DB connectivity issues. For example at one point Amazon restarted 
>> our DB (it's an RDS instance) and the workers started flailing, repeatedly 
>> raising the same exceptions despite the DB coming back online. Later on we 
>> discovered that we could fix this particular issue by calling 
>> django.db.connection.close() when this exception occurred (it happened to be 
>> InterfaceError); on the next attempt to interact w/ the DB Django would 
>> establish a new connection to the DB and everything would continue to work. 
>> More recently a new error occurred that caused a similar problem, leading us 
>> to speculate that we should do the same thing in this case with this new 
>> type of exception (I think now it's OperationalError because the DB went 
>> into "recovery mode" or something).
>>
>
>You're right. Django is not really designed to be held open in this manner.
>
>> We are now planning on refactoring this service a bit so that instead of 
>> attempting to recover from exceptions, we'll just terminate the process and 
>> configure an external agent to automatically restart in the face of 
>> unexpected errors. This feels like a safer design than trying to figure out 
>> every exception type we should be handling. However I wanted to reach out to 
>> the Django group as a sanity check to see if we're missing something more 
>> basic. From browsing various tickets in Django's issue tracker I've gotten 
>> the impression that we may be swimming upstream a little bit as Django is 
>> designed as a web framework and relies on DB connections being closed or 
>> returned to a pool or something automatically at the end of the request 
>> cycle, not held open by a single loop in a long-running process. Is there 
>> something special we should be doing in these worker processes? A special 
>> Django setting perhaps? Should we just be calling connection.close() after 
>> processing each event? Should we not be using Django at all in this case?
>>
>
>The answer is yes, you can/should use Django, but not to the extent of your 
>current implementation. Your long running jobs should be collected by Django 
>and passed off immediately to a batch processor designed for long-running jobs 
>(although your jobs may not be long-running, it sounds like you are just 
>waiting for incoming job requests).
>
>Celery is a popular choice for batch processing with Django. It has hooks 
>built specifically for Django, and is well documented. It does require a 
>message broker such as Redis or RabbitMQ to keep track of the jobs, though. 
>However, it is designed to work directly with your Django instance, including 
>support for the ORM against your existing database.
>
>http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
>
>> I think the pessimistic kill-and-restart strategy we've decided upon for now 
>> will work, but any guidance here to ensure we aren't fighting against our 
>> own framework would be much appreciated.
>>
>
>My recommendation would be to investigate a batch processor such as Celery. 
>Depending on 

Re: Using the Django ORM in a long-running worker process

[Daniel Tao]

Thank you for the thorough response, which has proven very helpful, mainly 
by reinforcing what I was growing to suspect: we've updated the code in our 
worker processes to close the DB connection after every message, and sure 
enough we've seen a huge improvement in the form of significantly fewer 
open DB connections at any given time (where things stood, we were coming 
dangerously close to hitting the limit set by RDS).

To clarify: these aren't really "jobs" as you probably mean. We are very 
familiar with celery; in fact we use it in our product for background 
tasks! The worker processes I'm talking about do not receive jobs to 
execute, they process raw messages in very high volume and are more 
purpose-built to handle them in a specific way.

But that isn't really important or interesting to a general audience. 
Really I just wanted to say thanks for the tip—it definitely nudged us in 
the right direction.

On Wednesday, August 17, 2016 at 1:49:22 AM UTC-5, James Schneider wrote:
>
>
> > My team has built a service comprising 3 main parts, a web application 
> and 2 long-running worker processes that process events from a message 
> exchange. All of these components interact with the same database and use 
> the same underlying Django "app" for ORM models (i.e. the 2 worker 
> processes call django.setup() on initialization).
> >
>
> Are the two long term worker instances Django processes, or some other 
> process? If they are Django workers, you're probably not handling jobs 
> correctly.
>
> > We've had some issues with the worker processes failing to recover in 
> the face of DB connectivity issues. For example at one point Amazon 
> restarted our DB (it's an RDS instance) and the workers started flailing, 
> repeatedly raising the same exceptions despite the DB coming back online. 
> Later on we discovered that we could fix this particular issue by calling 
> django.db.connection.close() when this exception occurred (it happened to 
> be InterfaceError); on the next attempt to interact w/ the DB Django would 
> establish a new connection to the DB and everything would continue to work. 
> More recently a new error occurred that caused a similar problem, leading 
> us to speculate that we should do the same thing in this case with this new 
> type of exception (I think now it's OperationalError because the DB went 
> into "recovery mode" or something).
> >
>
> You're right. Django is not really designed to be held open in this manner.
>
> > We are now planning on refactoring this service a bit so that instead of 
> attempting to recover from exceptions, we'll just terminate the process and 
> configure an external agent to automatically restart in the face of 
> unexpected errors. This feels like a safer design than trying to figure out 
> every exception type we should be handling. However I wanted to reach out 
> to the Django group as a sanity check to see if we're missing something 
> more basic. From browsing various tickets in Django's issue tracker I've 
> gotten the impression that we may be swimming upstream a little bit as 
> Django is designed as a web framework and relies on DB connections being 
> closed or returned to a pool or something automatically at the end of the 
> request cycle, not held open by a single loop in a long-running process. Is 
> there something special we should be doing in these worker processes? A 
> special Django setting perhaps? Should we just be calling 
> connection.close() after processing each event? Should we not be using 
> Django at all in this case?
> >
>
> The answer is yes, you can/should use Django, but not to the extent of 
> your current implementation. Your long running jobs should be collected by 
> Django and passed off immediately to a batch processor designed for 
> long-running jobs (although your jobs may not be long-running, it sounds 
> like you are just waiting for incoming job requests).
>
> Celery is a popular choice for batch processing with Django. It has hooks 
> built specifically for Django, and is well documented. It does require a 
> message broker such as Redis or RabbitMQ to keep track of the jobs, though. 
> However, it is designed to work directly with your Django instance, 
> including support for the ORM against your existing database.
>
> http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
>
> > I think the pessimistic kill-and-restart strategy we've decided upon for 
> now will work, but any guidance here to ensure we aren't fighting against 
> our own framework would be much appreciated.
> >
>
> My recommendation would be to investigate a batch processor such as 
> Celery. Depending on the number of jobs you are running, if you have 
> individual jobs running rather than a long process, the chances of a DB 
> restart causing panic are mitigated to just the few jobs that happen to run 
> at that moment. You also have granular control over the failure behavior of 
> individual jobs. Some may 

Re: receiving PNG file in django

[Aron Griffis]

Hi Larry,

I think you'll find what you're looking for in request.FILES, see
https://docs.djangoproject.com/en/1.10/ref/request-response/#django.http.HttpRequest.FILES
and https://docs.djangoproject.com/en/1.10/ref/files/uploads/#uploaded-files

This is the same as using cgi.FieldStorage to parse files from a submitted
multipart/form-data. You can then call .read() on the UploadedFile object,
or better yet use .chunks() to copy to your final destination without
overwhelming memory.

-Aron


On Fri, Aug 19, 2016 at 4:17 PM, Larry Martell 
wrote:

> I have a falcon server that I am trying to port to django. One of the
> falcon endpoints processes a request that contains a PNG file sent
> with content_type = 'application/octet-stream'. It writes the data to
> a file maintaining the correct PNG structure.
>
> The falcon code does this:
>
> form = cgi.FieldStorage(fp=req.stream, environ=req.env)
>
> and then writes the png like this:
>
> fd.write(form[key].file.read())
>
> I cannot figure out how to do the same thing in django. When my view
> is called the data in request.POST[key] has already been decoded to
> unicode text and it's no longer valid png data.
>
> How can I do this with django? Should/can I use cgi.FieldStorage? The
> request I get (of type django.core.handlers.wsgi.WSGIRequest) does not
> have a stream method. I'm sure there's some way to do this, but I have
> not come up with anything googling.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CACwCsY5m4fdczXdQ0gYX61gBe0BYQ-ZoZ1R_vpkrGEzv%2B2-vBg%
> 40mail.gmail.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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKDfzeA7DKV2hEr89vELLZYru-57THK5HUus8ZKH6g_SbunPUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django query not returning all objects

[Constantine Covtushenko]

Hi Koonal,

Sorry for not exact suggestion.

I hope that combination of  `annotate` and `values` will be helpful, see
this link for more detailed explanation
.

Pleas try something like following:

cases = HeartFlowCase.objects.values(‘all fields required in your view’).
annotate(min_deadline=Min('data__deadline')).order_by('min_deadline')

It is the Todor's suggestion extended with value method run.

I believe that you need `GROUP BY` in your SQL query and it generated by
`values` as said in Django documentation.

On Fri, Aug 19, 2016 at 7:10 PM, Simon Charette 
wrote:

> For reference there's a Django ticket to suggest using this technique.
>
> Cheers,
> Simon
>
> [1] https://code.djangoproject.com/ticket/19842
>
>
> Le jeudi 18 août 2016 02:20:34 UTC-4, Todor Velichkov a écrit :
>>
>> Another solution would be to annotate min/max deadline date and order by
>> the annotation. Something like:
>>
>> cases = HeartFlowCase.objects.all().annotate(min_deadline=Min('data_
>> _deadline')).order_by('min_deadline')
>>
>>
>> On Thursday, August 18, 2016 at 7:59:19 AM UTC+3, Constantine Covtushenko
>> wrote:
>>>
>>> Hi Koonal,
>>>
>>> As said in django doc
>>>  you
>>> can use `distinct()` to remove duplicated rows from first query.
>>>
>>> I believe with this your pagination should works as expected.
>>>
>>> Regards,
>>>
>>>
>>> On Thu, Aug 18, 2016 at 2:58 AM, Koonal Bharadwaj <
>>> kbhar...@heartflow.com> wrote:
>>>
 Hello,

 The issue:

 When trying to order_by on a related model duplicate entries are
 created. I solved this with an OrderedSet that is applied after paginating 
 (
 http://code.activestate.com/recipes/576694/). However, when I try to
 paginate the queryset, all the results are not returned. It's missing a few
 table rows.

 Models:

 class HeartFlowCase(models.Model):
 """

 A Hearflow Case.

 This serves at the true state of a case as it is processed through the 
 system.
 It also holds the results of each step of the processing.

 """

 # Primary
 hf_id = models.CharField('HeartFlow ID', max_length=200, blank=True, 
 unique=True)
 canonical_data = models.ForeignKey('cases.CaseData', to_field='uuid', 
 related_name="canonical_data")


 class CaseData(models.Model):
 """
 Extracted and computed values related to a single processing run of a 
 case.

 A HeartFlowCase can have multiple runs associated with it.
 The one which is accepted to be the "clinically accurate" one is the 
 one referred to as 'canonical_data' by
 the HeartFlowCase itself.

 """

 # Primary
 heartflowcase = models.ForeignKey(HeartFlowCase, related_name='data', 
 blank=True, null=True)
 uuid = models.CharField('Case Data UUID', max_length=200, blank=False, 
 null=False, unique=True)
 deadline = models.DateTimeField('Deadline', blank=True, 
 default=get_default_deadline)


 As you can see, there is a ForeignKey to canonical CaseData from
 HeartFlowCase and a ForeignKey to HeartFlowCase from CaseData. So you
 can have multiple CaseDatas per HeartFlowCase.

 Structure:

 HeartFlowCase
 |
 data - CaseData1
 \
  \ CaseData2


 For example:

 Total number of HeartFlow objects are 5 with 2 CaseDatas each. If I
 order_by deadline on CaseData as:
 cases = HeartFlowCase.objects.all().order_by(data__deadline)
 this returns duplicates since there are multiple CaseDatas, which is
 fine. Now I try and paginate it by applying:

 paginator = Paginator(cases, 2)
 cases = paginator.page(1)

 Now the SQL query has a LIMIT and OFFSET given. If the order_by gives 
 duplicate HeartFlowCase objects this hits the LIMIT number and the results 
 that are returned are missing a HeartFlowCase object. So if 2 duplicates 
 are returned per case after applying the OrderedSet I get only one case 
 back and missing one case since it was never returned from the database. 
 As I goto the next page:

 cases = paginator.page(2)

 that missingHeartFlowCase object that was not returned from the first page 
 queryset is lost forever and is never displayed.


 I hope this is clear. Please let me know if I can clarify further. Any 
 help would greatly be appreciated. 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...@googlegroups.com.
 To post to this group, send email to 

Re: Starting new project -- version 1.10

[Rich Shepard]

On Fri, 19 Aug 2016, Tim Graham wrote:


Don't use the same name for your app and project. When you "startproject
crm", the project settings.py, urls.py, and wsgi.py are placed in a module
named "crm" so you can't use the same name for an app.


Tim,

  I read that but overlooked the implications.

Thanks very much,

Rich

Re: Starting new project -- version 1.10

[Tim Graham]

Don't use the same name for your app and project. When you "startproject 
crm", the project settings.py, urls.py, and wsgi.py are placed in a module 
named "crm" so you can't use the same name for an app.

On Friday, August 19, 2016 at 2:54:56 PM UTC-4, Rich Shepard wrote:
>
>   I'm working my way through the tutorial and creating the application I 
> want rather than the articles example. I've become stuck between two 
> sections of the tutorial. 
>
>Creating the project (section 2.3.1 worked fine from the TLD, 
> ~/development/: 
>
> django-admin startproject crm 
>
> created ~/development/crm/ containing the files it should (page 14). 
>
>Moving to section 2.3.2 I start the runserver and, sure enough, I can 
> see 
> the web page it created. 
>
>The problem occurs in section 2.3.3 when I try to create the crm 
> application. I cannot do this while the development server is running; 
> there 
> is no system or python prompt. When I kill the running development server 
> (^C), and issue the command 
>  python3 manage.py startapp crm 
>
> I'm told that application already exists: 
>  ~/development/crm]$ python3 manage.py startapp crm 
>  CommandError: 'crm' conflicts with the name of an existing Python 
> module and 
>  cannot be used as an app name. Please try another name. 
> but I have no idea where django thinks it exists. 
>
>Not all the files are found: 
>  ~/development/crm/crm]$ ls 
>  __init__.py  __pycache__/  settings.py  urls.py  wsgi.py 
>
> These were created by the startproject command. 
>
>Now knowing how I dug this hole I'm in I'd appreciate your teaching me 
> how 
> to get out of the hole and move on. 
>
> Rich 
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/df6cf569-2b52-4244-8e33-8c2c24dbb497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Feedback requested] Django Debug Toolbar: Removal of automatic setup

[Matthias Kestenholz]

Hi everyone,

I wanted to solicit some feedback on the removal of automatic setup before 
moving forward with it. There's a pull request[1] by Jon Dufresne which 
removes the feature, and if anyone feels strongly about it now would be the 
time to speak up. The documentation encourages users to use the explicit 
setup, and automatic setup is only kept for backwards compatibility[2] 
therefore this change shouldn't be too surprising, at least for those 
reading the documentation.

Thanks,
Matthias


[1]: https://github.com/jazzband/django-debug-toolbar/pull/851
[2]: 
http://django-debug-toolbar.readthedocs.io/en/stable/installation.html#automatic-setup


-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9640168a-7b34-428f-9ee5-5a1d96c6b1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Learning django and python from Tutorials,

[K.R. O'Connell]

 I made the App called polls, Nifty!
 Now I need to edit the homepage of the site?
I can't figure which template to edit?
Any help would be appreciated
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e4c1b49c-1764-4570-9288-dd1d5e2908b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

receiving PNG file in django

[Larry Martell]

I have a falcon server that I am trying to port to django. One of the
falcon endpoints processes a request that contains a PNG file sent
with content_type = 'application/octet-stream'. It writes the data to
a file maintaining the correct PNG structure.

The falcon code does this:

form = cgi.FieldStorage(fp=req.stream, environ=req.env)

and then writes the png like this:

fd.write(form[key].file.read())

I cannot figure out how to do the same thing in django. When my view
is called the data in request.POST[key] has already been decoded to
unicode text and it's no longer valid png data.

How can I do this with django? Should/can I use cgi.FieldStorage? The
request I get (of type django.core.handlers.wsgi.WSGIRequest) does not
have a stream method. I'm sure there's some way to do this, but I have
not come up with anything googling.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY5m4fdczXdQ0gYX61gBe0BYQ-ZoZ1R_vpkrGEzv%2B2-vBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Starting new project -- version 1.10

[Rich Shepard]

  I'm working my way through the tutorial and creating the application I
want rather than the articles example. I've become stuck between two
sections of the tutorial.

  Creating the project (section 2.3.1 worked fine from the TLD,
~/development/:

django-admin startproject crm

created ~/development/crm/ containing the files it should (page 14).

  Moving to section 2.3.2 I start the runserver and, sure enough, I can see
the web page it created.

  The problem occurs in section 2.3.3 when I try to create the crm
application. I cannot do this while the development server is running; there
is no system or python prompt. When I kill the running development server
(^C), and issue the command
python3 manage.py startapp crm

I'm told that application already exists:
~/development/crm]$ python3 manage.py startapp crm
CommandError: 'crm' conflicts with the name of an existing Python 
module and
cannot be used as an app name. Please try another name.
but I have no idea where django thinks it exists.

  Not all the files are found:
~/development/crm/crm]$ ls
__init__.py  __pycache__/  settings.py  urls.py  wsgi.py

These were created by the startproject command.

  Now knowing how I dug this hole I'm in I'd appreciate your teaching me how
to get out of the hole and move on.

Rich

Re: Unable to get tests to work

[Matt]

I purged all the '*.pyc' and the result remains the same. The missing pyc 
files could be explained by that I use Pycharm to dev in. It appears that 
this IDE cleans those up automatically. Also I have been dropping to a 
shell trying to test things to resolve the issue, which would explain why 
there are some pyc files but not all.

pytest was an attempt to resolve the issue outside of django's manage.py. 
It failed as well. Here is the pytest.ini:

[pytest]
DJANGO_SETTINGS_MODULE=refreshes.settings

Thanks,
Matt

On Friday, August 19, 2016 at 10:37:51 AM UTC-6, Fred Stluka wrote:
>
> Matt,
>
> At a glance, the directory structure looks OK.  Seems odd though
> that you have some *.pyc files with no corresponding *.py file.
> For example, frontend/tests.pyc and nas/tests.pyc.  Could such 
> a file be tripping up the test runner?  That might explain why it 
> fails when no arguments -- searching for all tests and getting 
> confused -- but succeeds when told to run only backups.tests.
>
> Same for all of the erp/*.pyc files.
>
> Perhaps try deleting all *.pyc file in the entire tree and then run
> the tests, letting them be recreated from the *.py files as needed.
>
> Also, I see a backup/tests.py with no *.pyc file.  Is there a syntax 
> error in that file that makes it not compile?  Or is it just not 
> getting that far?
>
> Also, what is in pytest.ini?  Is it perhaps directing the test runner 
> to look for tests that don't exist?
>
> --Fred 
> --
> Fred Stluka -- mailt...@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 8/18/16 3:49 PM, Matt wrote:
>
> Sorry replied to the wrong thread: https://dpaste.de/OF8j
>
> On Wednesday, August 17, 2016 at 11:16:27 PM UTC-6, Gergely Polonkai 
> wrote: 
>>
>> Hello,
>>
>> this “refreshes.backups.tests” thing bothers me a lot. Could you show us 
>> your directory structure, please?
>>
>> Best,
>> Gergely 
>>
>> On Wed, Aug 17, 2016, 23:03 Matt  wrote:
>>
>>> Ok a step forward. When I spell out the tests it works:  
>>>
>>> https://dpaste.de/2MXf
>>>
>>> But when I run test without arguments, it fails out:
>>>
>>> https://dpaste.de/cgTH
>>>
>>> There is more than the backups app here, but I plan to replicate out the 
>>> fix when I get it.
>>>
>>> On Wednesday, August 17, 2016 at 2:34:45 PM UTC-6, Fred Stluka wrote:
>>>
 Matt,

 Oops!  Right.  I just noticed that in the dpaste.

 My next guess is you may need to change the name "good_index_text"
 to something that starts with "test_" to get it to be recognized as a 
 test.

 Or maybe something to do with "refreshes"?  The test trace shows
 it trying to run testcase "refreshes.backups.tests", but in the manual
 import you did from the python shell, you only import "backups.tests"

 --Fred 
 --

>>> Fred Stluka -- mailt...@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 8/17/16 4:27 PM, Matt wrote:

>>> Sorry for the typo, but I have already do that way. I have the output in 
 the the first link.

 On Wednesday, August 17, 2016 at 2:24:19 PM UTC-6, Fred Stluka wrote: 
>
> Matt,
>
> Drop the "s" from "tests":
>
> ./manage.py test backups
>
> --Fred 
> --
> Fred Stluka -- mailt...@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 8/17/16 4:17 PM, Matt wrote:
>
> When I'm trying to get tests to work it simply states that its unable 
> to import .tests. I'm not sure what I'm missing here. Here is some 
> output please let me know if you need more: 
>
> ./manage.py tests backups
> https://dpaste.de/4U9C
>
> The test file:
> https://dpaste.de/bBZt
> -- 
> 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...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/89d6fac7-0848-4e35-8b4a-62d24178c3aa%40googlegroups.com
>  
> 

Re: Unable to get tests to work

[Fred Stluka]

  
  
Matt,

At a glance, the directory structure looks OK.  Seems odd though
that you have some *.pyc files with no corresponding *.py file.
For example, frontend/tests.pyc and nas/tests.pyc.  Could such 
a file be tripping up the test runner?  That might explain why it 
fails when no arguments -- searching for all tests and getting 
confused -- but succeeds when told to run only backups.tests.

Same for all of the erp/*.pyc files.

Perhaps try deleting all *.pyc file in the entire tree and then run
the tests, letting them be recreated from the *.py files as needed.

Also, I see a backup/tests.py with no *.pyc file.  Is there a syntax

error in that file that makes it not compile?  Or is it just not 
getting that far?

Also, what is in pytest.ini?  Is it perhaps directing the test
runner 
to look for tests that don't exist?

--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 8/18/16 3:49 PM, Matt wrote:


  Sorry replied to the wrong
thread: https://dpaste.de/OF8j

On Wednesday, August 17, 2016 at 11:16:27 PM UTC-6, Gergely
Polonkai wrote:

  Hello,
  this “refreshes.backups.tests” thing bothers me a
lot. Could you show us your directory structure, please?
  Best,
Gergely 
  
  
On Wed, Aug 17, 2016, 23:03 Matt 
  wrote:


  Ok a step forward. When I spell out the
tests it works: 


https://dpaste.de/2MXf


But when I run test without arguments, it fails
  out:


https://dpaste.de/cgTH


There is more than the backups app here, but I plan
  to replicate out the fix when I get it.

  
  

  
On Wednesday, August 17, 2016 at 2:34:45 PM UTC-6,
Fred Stluka wrote:

  
  

  

   Matt,

  

  

  
  

  

   Oops! 
Right.  I just noticed that in the dpaste.

My next guess is you may need to change the name
"good_index_text"
to something that starts with "test_" to get it
to be recognized as a 
test.

Or maybe something to do with "refreshes"?  The
test trace shows
it trying to run testcase
"refreshes.backups.tests", but in the manual
import you did from the python shell, you only
import "backups.tests"

  

  

  
  

  

  
--Fred 
  
  

  

  
  

  

  
 Fred Stluka -- mailt...@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 8/17/16 4:27 PM, Matt wrote:

  

  

  
  

  

  

  Sorry for the typo, but I have

Re: Django query not returning all objects

[Simon Charette]

For reference there's a Django ticket to suggest using this technique.

Cheers,
Simon

[1] https://code.djangoproject.com/ticket/19842

Le jeudi 18 août 2016 02:20:34 UTC-4, Todor Velichkov a écrit :
>
> Another solution would be to annotate min/max deadline date and order by 
> the annotation. Something like:
>
> cases = HeartFlowCase.objects.all().annotate(min_deadline=Min(
> 'data__deadline')).order_by('min_deadline')
>
>
> On Thursday, August 18, 2016 at 7:59:19 AM UTC+3, Constantine Covtushenko 
> wrote:
>>
>> Hi Koonal,
>>
>> As said in django doc 
>>  you 
>> can use `distinct()` to remove duplicated rows from first query.
>>
>> I believe with this your pagination should works as expected.
>>
>> Regards,
>>
>>
>> On Thu, Aug 18, 2016 at 2:58 AM, Koonal Bharadwaj > > wrote:
>>
>>> Hello,
>>>
>>> The issue:
>>>
>>> When trying to order_by on a related model duplicate entries are 
>>> created. I solved this with an OrderedSet that is applied after paginating (
>>> http://code.activestate.com/recipes/576694/). However, when I try to 
>>> paginate the queryset, all the results are not returned. It's missing a few 
>>> table rows. 
>>>
>>> Models:
>>>
>>> class HeartFlowCase(models.Model):
>>> """
>>>  
>>> A Hearflow Case.
>>>  
>>> This serves at the true state of a case as it is processed through the 
>>> system.
>>> It also holds the results of each step of the processing.
>>>
>>> """
>>>
>>> # Primary
>>> hf_id = models.CharField('HeartFlow ID', max_length=200, blank=True, 
>>> unique=True)
>>> canonical_data = models.ForeignKey('cases.CaseData', to_field='uuid', 
>>> related_name="canonical_data")
>>>
>>>
>>> class CaseData(models.Model):
>>> """
>>> Extracted and computed values related to a single processing run of a 
>>> case.
>>>
>>> A HeartFlowCase can have multiple runs associated with it.
>>> The one which is accepted to be the "clinically accurate" one is the 
>>> one referred to as 'canonical_data' by
>>> the HeartFlowCase itself.
>>>
>>> """
>>>
>>> # Primary
>>> heartflowcase = models.ForeignKey(HeartFlowCase, related_name='data', 
>>> blank=True, null=True)
>>> uuid = models.CharField('Case Data UUID', max_length=200, blank=False, 
>>> null=False, unique=True)
>>> deadline = models.DateTimeField('Deadline', blank=True, 
>>> default=get_default_deadline)
>>>
>>>
>>> As you can see, there is a ForeignKey to canonical CaseData from 
>>> HeartFlowCase and a ForeignKey to HeartFlowCase from CaseData. So you 
>>> can have multiple CaseDatas per HeartFlowCase. 
>>>
>>> Structure:
>>>
>>> HeartFlowCase
>>> |
>>> data - CaseData1
>>> \
>>>  \ CaseData2
>>>
>>>
>>> For example: 
>>>
>>> Total number of HeartFlow objects are 5 with 2 CaseDatas each. If I 
>>> order_by deadline on CaseData as: 
>>> cases = HeartFlowCase.objects.all().order_by(data__deadline)
>>> this returns duplicates since there are multiple CaseDatas, which is 
>>> fine. Now I try and paginate it by applying:
>>>
>>> paginator = Paginator(cases, 2)
>>> cases = paginator.page(1)
>>>
>>> Now the SQL query has a LIMIT and OFFSET given. If the order_by gives 
>>> duplicate HeartFlowCase objects this hits the LIMIT number and the results 
>>> that are returned are missing a HeartFlowCase object. So if 2 duplicates 
>>> are returned per case after applying the OrderedSet I get only one case 
>>> back and missing one case since it was never returned from the database. As 
>>> I goto the next page:
>>>
>>> cases = paginator.page(2)
>>>
>>> that missingHeartFlowCase object that was not returned from the first page 
>>> queryset is lost forever and is never displayed. 
>>>
>>>
>>> I hope this is clear. Please let me know if I can clarify further. Any help 
>>> would greatly be appreciated. 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...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/61ec03f6-3325-49fe-bcdc-a7ca50784dc0%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 

Re: Odd problem: some database updates do not appear on other pages until server restart

[bobhaugen]

Michal, thanks for following up.

I'll try your suggested code from your other response upthread and see if 
it solves the problem as well as the form.__init__.

And do more digging about how Python does things. I am a self-taught 
programmer who focuses on community economic development and I usually just 
learn as much about software as I need to do what I want to do. Sometimes 
that is not enough learning...;-)

On Friday, August 19, 2016 at 8:13:08 AM UTC-5, Michal Petrucha wrote:
>
> On Fri, Aug 19, 2016 at 02:38:02PM +0200, Michal Petrucha wrote: 
> > On Fri, Aug 19, 2016 at 05:02:39AM -0700, bobhaugen wrote: 
> > > On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote: 
> > > These questions remain unanswered, although I intend to do a bunch 
> more 
> > > testing: 
> > > 
> > >1. How pervasive is this problem? Does it affect template variables 
> like 
> > >{{ object.foreign_key_method }} where the foreign_key_method 
> returns a 
> > >queryset? 
> > >2. Is this behavior clearly documented anywhere? 
> > 
> > Honestly, I'm not sure what exactly you're asking here. Your 
> > implementation of ``with_user`` was hard-wiring a queryset filter 
> > based on the state of the database at the time ``with_user`` was 
> > called. The rest is just standard Python behavior – since the method 
> > was called during import (in the ModelForm definition), the result of 
> > that call was used for the rest of the process' lifetime. 
>
> Actually, let me rephrase that. This problem you encountered here 
> wasn't a case of “you need to set the ``queryset`` argument of 
> ``ModelChoiceField`` in your form's ``__init__``,” but rather a case 
> of “don't do too much filtering in your Python code – let your 
> database do the filtering”. 
>
> Using ``__init__`` to set the queryset is not really a very standard 
> thing to do. It's just a workaround to make a form work if it uses a 
> manager or queryset method that does not behave entirely correctly. 
>
> Does this help make things at least a little bit clearer? 
>
> Michal 
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/697f546d-b6df-4c2e-bf00-f8c5d16665f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Fri, Aug 19, 2016 at 02:38:02PM +0200, Michal Petrucha wrote:
> On Fri, Aug 19, 2016 at 05:02:39AM -0700, bobhaugen wrote:
> > On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
> > These questions remain unanswered, although I intend to do a bunch more 
> > testing:
> > 
> >1. How pervasive is this problem? Does it affect template variables like 
> >{{ object.foreign_key_method }} where the foreign_key_method returns a 
> >queryset?
> >2. Is this behavior clearly documented anywhere?
> 
> Honestly, I'm not sure what exactly you're asking here. Your
> implementation of ``with_user`` was hard-wiring a queryset filter
> based on the state of the database at the time ``with_user`` was
> called. The rest is just standard Python behavior – since the method
> was called during import (in the ModelForm definition), the result of
> that call was used for the rest of the process' lifetime.

Actually, let me rephrase that. This problem you encountered here
wasn't a case of “you need to set the ``queryset`` argument of
``ModelChoiceField`` in your form's ``__init__``,” but rather a case
of “don't do too much filtering in your Python code – let your
database do the filtering”.

Using ``__init__`` to set the queryset is not really a very standard
thing to do. It's just a workaround to make a form work if it uses a
manager or queryset method that does not behave entirely correctly.

Does this help make things at least a little bit clearer?

Michal

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160819131204.GK27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Odd problem: some database updates do not appear on other pages until server restart

[bobhaugen]

On Friday, August 19, 2016 at 7:38:45 AM UTC-5, Michal Petrucha wrote:
>
> Honestly, I'm not sure what exactly you're asking here. Your 
> implementation of ``with_user`` was hard-wiring a queryset filter 
> based on the state of the database at the time ``with_user`` was 
> called. The rest is just standard Python behavior – since the method 
> was called during import (in the ModelForm definition), the result of 
> that call was used for the rest of the process' lifetime. 
>
 
Ok, so from your response and that of Coues Ludovic upthread, I clearly 
need to study Python more deeply. Will do.

Thanks for all the responses.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bde5f813-155b-438b-9850-4311be2541b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Fri, Aug 19, 2016 at 05:02:39AM -0700, bobhaugen wrote:
> On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
> >
> > Could you show us the code of with_user? Maybe it does not return an 
> > unevaluated queryset? 
> >
> >  
> def with_user(self):
> all_agents = EconomicAgent.objects.all()
> ua_ids = []
> for agent in all_agents:
> if agent.users.all():
> ua_ids.append(agent.id)
> return EconomicAgent.objects.filter(id__in=ua_ids)
> 
> Moving the call to with_user to form.__init__ solved the problem in the 
> form ModelChoiceField.

Thanks for sharing the code. The problem is that the ``with_user``
method, which was called during import, eagerly evaluates
``EconomicAgent.objects.all()`` right away, and returns a QuerySet
filtered by the result of that. So even though the final queryset
returned by ``with_user`` is not yet evaluated, the filtering
condition in that queryset is already fixed.

You could fix this by doing something along the lines of::

def with_user(self):
return EconomicAgent.objects.filter(users__isnull=False).distinct()

The important difference is that this version of ``with_user`` does
not evaluate anything eagerly, but rather sets up the necessary
filters to get the correct result set at the time of evaluation of
that queryset.

Depending on what you do with the queryset further, you might need to
change it a little bit to remove the ``distinct()`` call, and use a
subquery instead.

> These questions remain unanswered, although I intend to do a bunch more 
> testing:
> 
>1. How pervasive is this problem? Does it affect template variables like 
>{{ object.foreign_key_method }} where the foreign_key_method returns a 
>queryset?
>2. Is this behavior clearly documented anywhere?

Honestly, I'm not sure what exactly you're asking here. Your
implementation of ``with_user`` was hard-wiring a queryset filter
based on the state of the database at the time ``with_user`` was
called. The rest is just standard Python behavior – since the method
was called during import (in the ModelForm definition), the result of
that call was used for the rest of the process' lifetime.

Cheers,

Michal

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160819123802.GJ27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Odd problem: some database updates do not appear on other pages until server restart

[ludovic coues]

You were calling the method in the class definition. The class is
"defined" when the module is imported. That's why things where
"cached". Module is imported only once.
The init method on the other hand is called every time an instance of
the class is created. I believe that method will be called in template
everytime the template is rendered.

I don't think this is clearly documented, but that's how python work.
there is nothing magic happening.

2016-08-19 14:02 GMT+02:00 bobhaugen :
> On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
>>
>> Could you show us the code of with_user? Maybe it does not return an
>> unevaluated queryset?
>>
>
> def with_user(self):
> all_agents = EconomicAgent.objects.all()
> ua_ids = []
> for agent in all_agents:
> if agent.users.all():
> ua_ids.append(agent.id)
> return EconomicAgent.objects.filter(id__in=ua_ids)
>
> Moving the call to with_user to form.__init__ solved the problem in the form
> ModelChoiceField.
>
> These questions remain unanswered, although I intend to do a bunch more
> testing:
>
> How pervasive is this problem? Does it affect template variables like {{
> object.foreign_key_method }} where the foreign_key_method returns a
> queryset?
> Is this behavior clearly documented anywhere?
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/e21e3ec0-dfba-4d0f-a4f0-828a552ee0af%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEuG%2BTZibykPMT6TiKHQpLvcAxPsTMu2YTXpDsHP5t4XWU_WWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd problem: some database updates do not appear on other pages until server restart

[bobhaugen]

On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
>
> Could you show us the code of with_user? Maybe it does not return an 
> unevaluated queryset? 
>
>  
def with_user(self):
all_agents = EconomicAgent.objects.all()
ua_ids = []
for agent in all_agents:
if agent.users.all():
ua_ids.append(agent.id)
return EconomicAgent.objects.filter(id__in=ua_ids)

Moving the call to with_user to form.__init__ solved the problem in the 
form ModelChoiceField.

These questions remain unanswered, although I intend to do a bunch more 
testing:

   1. How pervasive is this problem? Does it affect template variables like 
   {{ object.foreign_key_method }} where the foreign_key_method returns a 
   queryset?
   2. Is this behavior clearly documented anywhere?

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e21e3ec0-dfba-4d0f-a4f0-828a552ee0af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Thu, Aug 18, 2016 at 11:57:40AM -0700, bobhaugen wrote:
> On Thursday, August 18, 2016 at 1:34:29 PM UTC-5, Tim Graham wrote:
> >
> > I'd guess you're doing a query for the form field's choices at the module 
> > level which will be executed once and cached for as long as the server 
> > runs. See if 
> > https://docs.djangoproject.com/en/stable/ref/forms/fields/#fields-which-handle-relationships
> >  
> > helps, otherwise please post the code for the form in question.
> >
> > Ohhh, Tim! You might just have nailed it! Yes I am.
> 
> Here's the relevant code for the form field:
>  
> ```
> from_agent = forms.ModelChoiceField(
> required=False,
> queryset=EconomicAgent.objects.with_user(),
> ```
> 
> with_user() is a method of
> class AgentManager(models.Manager)

Could you show us the code of with_user? Maybe it does not return an
unevaluated queryset?

Cheers,

Michal

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160819101915.GI27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: query values() calls don't use transforms as filter() does

[Rishi Graham]

Thanks Tim,

This is a great addition, maybe I can do what I want with that (I'll have 
to think about it) but what I was hoping for is more within the lookup 
string itself.  A simple example (this is simplified from a stack overflow 
question I posted on this topic before I started poking around in the 
internals) would be if you have a Car model with options JSONField (using 
postgres).  Consider the two queries:

> Car.objects.filter(options__color='red')
> Car.objects.values('options__color')

The filter works because the lookup parser in build_filter calls 
get_transform, which knows how to key into the JSON field.  But the second 
query gives a join error because there is no call to get_transform in 
Query.add_fields (so "color" is assumed to be a relation).  I can get 
around this with an annotation and some RawSQL, but it's not very clean 
compared to making use of get_transform.

Thanks again for looking at this!
-Rishi.

On Thursday, August 18, 2016 at 6:44:25 PM UTC-7, Tim Graham wrote:
>
> I merged support for expressions in values() a few hours ago: 
> https://github.com/django/django/commit/39f35d4b9de223b72c67bb1d12e65669b4e1355b
>
> If that doesn't meet your needs, can you give an idea of what the QuerySet 
> you want would look like?
>
> On Thursday, August 18, 2016 at 5:10:41 PM UTC-4, Rishi Graham wrote:
>>
>> I noticed that the jsonb field indexing in postgres which is so handy in 
>> filtering does not seem to extend to calls to values().  After digging 
>> around a bit, it seems that sql.query.get_transform() is only called when 
>> building a filter, but not when adding fields for a values call. 
>>
>> Using transforms in both places was mentioned as part of the now closed 
>> feature request, #21863, which states that the "values() call will use 
>> always get_transform() so .values('hstorefield__exact') will work 
>> correctly”.   This was a little confusing because values does not use 
>> “lookup”, which seems to refer only to the comparison type extension in the 
>> filter string, but I am still relatively new to django so maybe I’m missing 
>> something. 
>>
>> I don’t see evidence of any further discussion of the effect on values 
>> calls.  Anyone know if this was on purpose, or just an oversight? 
>>
>> Thanks, 
>> -Rishi.
>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a70a4f35-6482-46f1-958f-e9fc6d8d93c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.