Re: State of X-Sendfile support?
Hi all,
Just to let you know that there's an X-Sendfile implementation for
WSGI apps (inc. Django), which also works with Nginx:
https://launchpad.net/wsgi-xsendfile
You can use it in Django views via twod.wsgi. For example:
"""
from twod.wsgi import call_wsgi_app
from xsendfile import NginxSendfile
file_sender = NginxSendfile('/var/www/docs')
file_sender_wsgi_app = XSendfileApplication('/media/documents',
file_sender)
def django_view(request, article_id):
article = Article.objects.get(article_id)
if it's foggy:
doc_response = call_wsgi_app(
file_sender_wsgi_app,
request,
article.path,
)
else:
doc_response = HttpResponseForbidden()
return doc_response
"""
That package is pretty stable, the only thing it's missing is
documentation which should be sorted soon.
Cheers.
- Gustavo.
On Mar 25, 6:50 am, Waldemar Kornewald wrote:
> On Thursday, March 24, 2011 2:40:39 PM UTC+1, Kristaps Kūlis wrote:
>
> > I wish to note that Nginx implements this feature differently than
> > LigHTTPd and Apache2
> >http://wiki.nginx.org/XSendfile,
>
> > Should django implementation consider that ?
>
> > My proposal to implement would be:
> > 1. HttpFileResponse which takes file location (relative to MEDIA_URL ?)
> > 2. HttpFileResponse checks for settings.X_SENDFILE or
> > settings.X_ACCEL_REDIRECT and modifies sets revelant headers
> > (Content-Type, X-Sendfile, X-Accel-Redirect) etc. HttpFileResponse
> > should fallback to outputting file if no accelerated redirect is
> > available.
> > 3. Update docs, showing example server config .
> > 4. Tests
>
> > I could provide patch, if design idea is ok .
>
> You might also be interested in this ticket which goes a little bit further
> in abstracting file uploads and downloads not only for X-Sendfile, but also
> S3, App Engine, and other file hosting/serving
> solutions:http://code.djangoproject.com/ticket/13960
>
> The patch is not great. It's too complicated, both implementation-wise (esp.
> in django.forms) and usability-wise (esp. the transfer_id stuff which is
> used for assigning backends to uploads/downloads).
>
> For the sake of completeness, here is a separate app with the same
> purpose:http://www.allbuttonspressed.com/projects/django-filetransfers
> The API can certainly be simplified some more and I plan to do that probably
> in May.
>
> I hope some of this is useful to you.
>
> Bye,
> Waldemar
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC Proposal] Customizable Serialization
Hi Russ,
Thanks for the long reply and all the suggestions. My comments are
inline.
> What if you need to support both? e.g.,
>
>
> the bar value
>
>
> It seems to me that you would be better served providing a way to
> annotate each individual metadata value as (and I'm bikeshedding a
> name here) 'major' or 'minor'. JSON would render all metadata as
> key-values, and XML can make the distinction and render minor metadata
> as attributes, and major metadata as tags.
>
I think that's a great idea, this can be implemented with decorators
on the methods like @tag or @attribute while setting one of them as
default when no decorator is applied.
> I think I see where you're going here. However, I'm not sure it
> captures the entire problem.
>
> Part of the problem with the existing serializers is that they don't
> account for the fact that there's actually two subproblems to
> serialization:
>
> 1) How do I output the value of a specific field
> 2) What is the gross structure of an object, which is a collection of
> fields plus, plus metadata about an object, plus
>
> So, for a single object the JSON serializer currently outputs:
>
> {
> "pk": 1,
> "model": "myapp.mymodel",
> "fields": {
> "foo": "foo value",
> "bar": "bar value"
> }
>
> }
>
> Implicit in this format is a bunch of assumptions:
>
> * That the primary key should be rendered in a different way to the
> rest of the fields
> * That I actually want to include model metadata like the model name
> * That the list of fields is an embedded structure rather than a list
> of top-level attributes.
> * That I want to include all the fields on the model
> * That I don't have any non-model or computed metadata that I want to include
I believe that my model of using a recursive method and storing
temporary data in 'levels' would address most of these concerns. The
method for handling a model would consist of the following steps,
roughly:
* Get the list of fields to be serialized.
* Now serialize each field , after checking for circular references
(see below), (using handle_field and apply all metadata, formatting
options etc) to a temporary python object, most probably as a key-
value in a dict.
* If an FK or M2M is encountered, check for nesting restrictions
and then recursively apply the handle_model method.
* Add model level metadata, formatting options.
* Process reverse relations, if required. (see below)
* Store the model in some container in the serializer object.
* Clear temp data in the current 'level'.
Finally, when all models are processed, dump the data from the
container into the required format.
> When you start dealing with foreign keys and m2m, you have an
> additional set of assumptions --
>
> * How far should I traverse relations?
The user can specify a limit to the levels of nesting through
variable ``max_nesting_depth``.
> * Do I traverse reverse relations?
In my opinion, traversing reverse relations can get really ugly at
times, especially when there are M2M fields, foreign keys or circular
relations involved. But there are some scenarios where the data is in
a relatively simpler format and serializing them would be useful. To
support this, I thought of something like this:
class Srz(Serializer):
...
reverse_relations = [ (from_model_type, to_model_type), ... ]
But this should be used with caution and avoided when possible.
> * How do I represent traversed objects? As FK values? As embedded objects?
As embedded objects, if the nesting depth limit is reached, then as FK
values.
> * If they're embedded objects, how do I represent *their* traversed values?
Their traversed values would be represented just as a normal model
would be, with field-value mappings. The user can choose which fields
to dump.
> * What happens with circular relations?
For all model type objects, like the base model in the query set and
all FK and M2M fields, some uniquely identifying data (like the
primary key, content type) will be stored in a list as each one of
them is processed. Before serializing a model, it would be checked if
the model is already on the list or not. If it is there, it is a
circular reference and that model would be ignored .
> * If I have two foreign keys on the same model, are they both
> serialized the same way?
Yes.
> When you start dealing with the XML serializer, you have all these
> problems and more (because you have the attribute/tag distinction for
> each of these decisions, too -- for example, I may want some fields to
> be rendered as attributes, and some as tags.
>
For XML, I thought of using an intermediary container for a node that
would store all these details.
> > -
> > New features in the serialize() function
> > -
> > Apart from the changes I’ve proposed for the ``fields`` argument of
> > serialize, I would like to add
Proposal - Handling arbitrary request Content-Types.
Hey All, This is somewhat related to the ticket “Process HTTP PUT into request.FILES and request.PUT as done for POST” [1], although much broader in scope. In that ticket there’s a link to a related discussion [2] where Malcolm Tredinnick explains why a request.PUT that mirrors the current request.POST behaviour isn’t the right thing to do. Obviously Malcom’s right that request.POST is a special case that’s limited to supporting browser form submissions, which means restricting it’s behaviour to requests with a method “POST” [3] and a content type of either “application/x-www-form-urlencoded” or “multipart/form-data” (and apparently “text/plain” as per HTML5) [4]. However, it would still be useful if Django provided built-in behaviour to be able to support accessing the content of HTTP requests for requests other than just form POSTs, at some higher level than simply forcing the developer to use request.read() or request.raw_post_content. I don’t want to get too bogged down in implementation details at this point, more just gauge a response to the proposal - if it’s a “that sounds like a decent idea”, or if it’s a “ain’t never gonna happen in core” kind of thing, so I’ll (try!) to keep it reasonably high level for now... So... Generic Content-Type support could be provided either by re-purposing the request.REQUEST attribute (obviously making sure it’s done in a backwards compatible way [*]), or by adding a new lazily evaluated request.CONTENT. The request.REQUEST/request.CONTENT would be used to return the parsed content of the request, as determined by a set of installed parsers. A request.content_parsers attribute would also be added to the request [**], which would default to initializing from settings.CONTENT_PARSERS, and would used to determine which parser would be used to de-serialize the request. Django could initially ship with a FormParser (And perhaps also some other useful defaults such as a JSONParser.) The default for settings.CONTENT_PARSERS would probably just include the FormParser. The FormParser would handle “application/x-www-form-urlencoded” and “multipart/form-data requests”, and return a QueryDict containing both the content data and uploaded files, reusing the existing MultiPartParser in it's implementation. (and respecting the existing upload_handlers for file uploads.) You would probably also want to add a ‘content_parsers’ view decorator that could be used to set the list of parsers used on a given request at the view level. That’d mean that usage would look something like this... def standard_view(request, *arg, **kwargs): request.POST[‘foo’] # Does not work for form PUT requests request.REQUEST[‘foo’] # Now works for form PUT requests @content_parsers(JSONParser) # NB. Decorator would take either a tuple/list or a single value def json_view(request, *args, **kwargs): request.REQUEST[‘foo’] # Works for application/json requests @content_parsers(BinaryUploadParser) def put_upload_view(request, *args, **kwargs): uploaded_file = request.REQUEST # An UploadedFile object (*NB, I’m not suggesting here that Parsers would be limited to returning pre-parsed objects, you might also create streaming parsers that return generator objects.) I like the idea because it follows the same pattern as request.POST but supplements the behaviour to support arbitrary methods and content-types, which is pretty core stuff for anyone trying to do any Web API stuff with Django. Forcing the developer to drop down to request.raw_post_content/request.read() isn’t particularly helpful if we could provide a nice flexible out of the box solution. Obviously there’d be a lots to thrash out, and there’s also some fiddly complexity there (EG handling request.raw_post_content, see ticket 9054 [5]) but what do you peeps think of the idea in general? Is it something that’d be valuable in core, would it only merit further discussion if there was a more explicitly detailed proposal, or if there was a reference implementation, or is it entirely out-of-scope? All of what I’ve mentioned could equally be implemented as Middleware, so would that make more sense than implementing it in core, and if it was done as Middleware would it still be useful for inclusion into Django? I realise it’s a fairly big proposal (esp. for a first post to the list) so feel free to go ahead and shoot me right down! :) Cheers, Tom Possible interface == settings.CONTENT_PARSERS# List of parsers, defaults to (contentparsers.FormParser,) HttpRequest.parsers # property, defaults to initializing from settings.CONTENT_PARSERS HttpRequest.REQUEST *or* .CONTENT # lazily evalulated, like request.POST class ContentParser(object) # Interface for parser objects. handles_request(request) parse(request) class FormParser(ContentParser) # Multipart and urlencoded behaviour, probably returns QueryDic
Re: State of X-Sendfile support?
Hi,
I look at your example code. You need to name the webserver in the
code. That's not very nice. I guess it should be possible to
guess the webserver (apache vs nginx) by looking at request.META.
Documentation would be nice
Thomas
On 25.03.2011 10:23, Gustavo Narea wrote:
> Hi all,
>
> Just to let you know that there's an X-Sendfile implementation for
> WSGI apps (inc. Django), which also works with Nginx:
> https://launchpad.net/wsgi-xsendfile
>
> You can use it in Django views via twod.wsgi. For example:
>
> """
> from twod.wsgi import call_wsgi_app
> from xsendfile import NginxSendfile
>
> file_sender = NginxSendfile('/var/www/docs')
> file_sender_wsgi_app = XSendfileApplication('/media/documents',
> file_sender)
>
> def django_view(request, article_id):
> article = Article.objects.get(article_id)
> if it's foggy:
> doc_response = call_wsgi_app(
> file_sender_wsgi_app,
> request,
> article.path,
> )
> else:
> doc_response = HttpResponseForbidden()
>
> return doc_response
> """
>
> That package is pretty stable, the only thing it's missing is
> documentation which should be sorted soon.
>
> Cheers.
>
> - Gustavo.
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
On 25 March 2011 12:34, Thomas Guettler wrote: > Hi, > > I look at your example code. You need to name the webserver in the > code. That's not very nice. I guess it should be possible to > guess the webserver (apache vs nginx) by looking at request.META. > -1 on guessing anything, especially something that doesn't change. Also, a fairly common configuration is Apache behind an nginx proxy. In this setup, I want nginx will be the one serving static files, not Apache. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
On Fri, 2011-03-25 at 12:55 +0100, Łukasz Rekucki wrote: > On 25 March 2011 12:34, Thomas Guettler wrote: > > I look at your example code. You need to name the webserver in the > > code. That's not very nice. I guess it should be possible to > > guess the webserver (apache vs nginx) by looking at request.META. > > > > -1 on guessing anything, especially something that doesn't change. > Also, a fairly common configuration is Apache behind an nginx proxy. > In this setup, I want nginx will be the one serving static files, not > Apache. Why guess in the first place? Apache and Nginx both support 'X-Sendfile: ' don't they? (older nginx seemed to only support their own syntax, though). -- pascal -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
On 25.03.2011 12:55, Łukasz Rekucki wrote: > On 25 March 2011 12:34, Thomas Guettler wrote: >> Hi, >> >> I look at your example code. You need to name the webserver in the >> code. That's not very nice. I guess it should be possible to >> guess the webserver (apache vs nginx) by looking at request.META. >> > > -1 on guessing anything, especially something that doesn't change. > Also, a fairly common configuration is Apache behind an nginx proxy. > In this setup, I want nginx will be the one serving static files, not > Apache. Maybe you are right. Guessing is bad. But I think to write "nginx" into the application code is bad, too. Something like this could be in settings.py. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django urls in JavaScript
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already, but as part of a
larger library (https://github.com/mlouro/olivejs/blob/master/olive/
urls/urls.js), both have been used in projects.
An example:
/* below is the output from "manage.py show_urls" in JSON format */
olive.urls.load({
'dashboard': '/dashboard/',
'time_edit': '/projects//time/save//',
'task_edit': '/projects//task/save//'
});
olive.urls.get('task_edit', {
'project_id': 2,
'task_id': 1
})
This all sounds pretty cool - I'd love to be able to reverse URLs in
JavaScript. Keep in mind, though, that URLConfs can change on a
per-request basis, by setting request.urlconf. Any JSON data structure
representing the URLConf would need to be generated after this has been
set (ie. some time after request middleware has been processed, look at
django.core.handlers.base:94-98). Having a template tag would probably
be fine, as the URLConf is set by render time, but don't expect to be
able to do a one-off analysis of the URLConf at application startup.
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Help wanted on a few Django community projects
Wow, I got a lot more responses to this than I'd thought, so I'd say I'm well on my way here. Thanks so much everyone -- y'all rock. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django 1.3: running test suit
Hi,
I've running (or trying) the django 1.3 test suite and I've got an
error with the next traceback...
Traceback (most recent call last):
File "/home/maxi/projects/django/django/tests/modeltests/fixtures/
tests.py", line 221, in test_compress_format_loading
''
File "/home/maxi/projects/django/django/django/test/testcases.py",
line 530, in assertQuerysetEqual
return self.assertEqual(map(transform, qs), values)
AssertionError: Lists differ: ['
- ['']
? ^
+ ['',
? ^
+ '']
I was looking into test_compress_format_loading function and I see
what try to load fixture4.json
Into fixture4.json I just have 1 object defined:
[
{
"pk": "6",
"model": "fixtures.article",
"fields": {
"headline": "Django pets kitten",
"pub_date": "2006-06-16 16:00:00"
}
}
]
Of course, the test fail.
Then, my question is
Is Ok what this test fail ?
What I'm doing wrong ?
Thanks in advance.
---
Maxi.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
We can't help you if you don't tell us a bit more about your system. What version of Python? What OS? Is there anything else unusual about your system or how you are running the tests? -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On 25 mar, 16:44, Paul McMillan wrote: > We can't help you if you don't tell us a bit more about your system. > What version of Python? What OS? I'm running django 1.3 from trunk. I'm using Ubuntu 10.04 and python 2.6.5 >Is there anything else unusual about > your system or how you are running the tests? > Mmm... yes there are something unusual. I'm testing the django-firebird backend and trying (or working hard) to run, at least, so many backend related test as I can. Yes, I know what firebird sql is not supported out the box with django but there are many firebird users who would like to use both. Anyway, there are something strange, because the json file just have one object and the test compare with two. What am I misinterpreting ? Best regards. -- Maxi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
The extra object is in the initial_data.json fixture which is loaded automatically. If you're not seeing that object than something is wrong with your initial_data fixture loading. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On 25 mar, 19:21, Gabriel Hurley wrote:
> The extra object is in the initial_data.json fixture which is loaded
> automatically. If you're not seeing that object than something is wrong with
> your initial_data fixture loading.
>
> - Gabriel
Hi Gabriel,
Thank for response.
I see now what I have an error when try to load modeltests/aggregation/
fixtures/initial_data.json
This is the traceback:
Problem installing fixture '/home/maxi/projects/django/django/tests/
modeltests/aggregation/fixtures/initial_data.json': Traceback (most
recent call last):
File "/home/maxi/projects/django/django/django/core/management/
commands/loaddata.py", line 174, in handle
obj.save(using=using)
File "/home/maxi/projects/django/django/django/core/serializers/
base.py", line 165, in save
models.Model.save_base(self.object, using=using, raw=True)
File "/home/maxi/projects/django/django/django/db/models/base.py",
line 553, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
File "/home/maxi/projects/django/django/django/db/models/
manager.py", line 195, in _insert
return insert_query(self.model, values, **kwargs)
File "/home/maxi/projects/django/django/django/db/models/query.py",
line 1436, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
django-firebird/firebird/compiler.py", line 114, in execute_sql
cursor = super(SQLCompiler, self).execute_sql(None)
File "/home/maxi/projects/django/django/django/db/models/sql/
compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
django-firebird/firebird/base.py", line 231, in execute
return self.cursor.execute(cquery, params)
DatabaseError: (-530, u'isc_dsql_execute: \n violation of FOREIGN KEY
constraint "CONTACT_ID_REFS_ID_48084965" on table
"AGGREGATION_BOOK"\n Foreign key reference target does not exist --
INSERT INTO "AGGREGATION_BOOK" ("ID", "ISBN", "NAME", "PAGES",
"RATING", "PRICE", "CONTACT_ID", "PUBLISHER_ID", "PUBDATE") VALUES (1,
159059725, The Definitive Guide to Django: Web Development Done Right,
447, 4.5, 30.00, 1, 1, 2007-12-06)')
Here, the problem seems to be what is trying to insert
aggregation.book contact_id (which refers to Author model) before to
insert aggregation.author.
In initial_data.json aggregation.author data come after to
aggregation.book which violate the referencial integrity.
Is it an error or I'm doing something wrong?
Thanks for you help.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On Fri, Mar 25, 2011 at 7:20 PM, maxi wrote:
> On 25 mar, 19:21, Gabriel Hurley wrote:
> > The extra object is in the initial_data.json fixture which is loaded
> > automatically. If you're not seeing that object than something is wrong
> with
> > your initial_data fixture loading.
> >
> > - Gabriel
>
> Hi Gabriel,
> Thank for response.
>
> I see now what I have an error when try to load modeltests/aggregation/
> fixtures/initial_data.json
>
> This is the traceback:
>
> Problem installing fixture '/home/maxi/projects/django/django/tests/
> modeltests/aggregation/fixtures/initial_data.json': Traceback (most
> recent call last):
> File "/home/maxi/projects/django/django/django/core/management/
> commands/loaddata.py", line 174, in handle
>obj.save(using=using)
> File "/home/maxi/projects/django/django/django/core/serializers/
> base.py", line 165, in save
>models.Model.save_base(self.object, using=using, raw=True)
> File "/home/maxi/projects/django/django/django/db/models/base.py",
> line 553, in save_base
>result = manager._insert(values, return_id=update_pk, using=using)
> File "/home/maxi/projects/django/django/django/db/models/
> manager.py", line 195, in _insert
>return insert_query(self.model, values, **kwargs)
> File "/home/maxi/projects/django/django/django/db/models/query.py",
> line 1436, in insert_query
>return query.get_compiler(using=using).execute_sql(return_id)
> File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> django-firebird/firebird/compiler.py", line 114, in execute_sql
>cursor = super(SQLCompiler, self).execute_sql(None)
> File "/home/maxi/projects/django/django/django/db/models/sql/
> compiler.py", line 735, in execute_sql
>cursor.execute(sql, params)
> File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> django-firebird/firebird/base.py", line 231, in execute
>return self.cursor.execute(cquery, params)
> DatabaseError: (-530, u'isc_dsql_execute: \n violation of FOREIGN KEY
> constraint "CONTACT_ID_REFS_ID_48084965" on table
> "AGGREGATION_BOOK"\n Foreign key reference target does not exist --
> INSERT INTO "AGGREGATION_BOOK" ("ID", "ISBN", "NAME", "PAGES",
> "RATING", "PRICE", "CONTACT_ID", "PUBLISHER_ID", "PUBDATE") VALUES (1,
> 159059725, The Definitive Guide to Django: Web Development Done Right,
> 447, 4.5, 30.00, 1, 1, 2007-12-06)')
>
>
> Here, the problem seems to be what is trying to insert
> aggregation.book contact_id (which refers to Author model) before to
> insert aggregation.author.
>
> In initial_data.json aggregation.author data come after to
> aggregation.book which violate the referencial integrity.
>
> Is it an error or I'm doing something wrong?
>
> Thanks for you help.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
This problem looks similar to one we see under MySQL InnoDB becaue it
doesn't properly support deferred constraints.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On 25 mar, 20:22, Alex Gaynor wrote:
> On Fri, Mar 25, 2011 at 7:20 PM, maxi wrote:
> > On 25 mar, 19:21, Gabriel Hurley wrote:
> > > The extra object is in the initial_data.json fixture which is loaded
> > > automatically. If you're not seeing that object than something is wrong
> > with
> > > your initial_data fixture loading.
>
> > > - Gabriel
>
> > Hi Gabriel,
> > Thank for response.
>
> > I see now what I have an error when try to load modeltests/aggregation/
> > fixtures/initial_data.json
>
> > This is the traceback:
>
> > Problem installing fixture '/home/maxi/projects/django/django/tests/
> > modeltests/aggregation/fixtures/initial_data.json': Traceback (most
> > recent call last):
> > File "/home/maxi/projects/django/django/django/core/management/
> > commands/loaddata.py", line 174, in handle
> > obj.save(using=using)
> > File "/home/maxi/projects/django/django/django/core/serializers/
> > base.py", line 165, in save
> > models.Model.save_base(self.object, using=using, raw=True)
> > File "/home/maxi/projects/django/django/django/db/models/base.py",
> > line 553, in save_base
> > result = manager._insert(values, return_id=update_pk, using=using)
> > File "/home/maxi/projects/django/django/django/db/models/
> > manager.py", line 195, in _insert
> > return insert_query(self.model, values, **kwargs)
> > File "/home/maxi/projects/django/django/django/db/models/query.py",
> > line 1436, in insert_query
> > return query.get_compiler(using=using).execute_sql(return_id)
> > File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> > django-firebird/firebird/compiler.py", line 114, in execute_sql
> > cursor = super(SQLCompiler, self).execute_sql(None)
> > File "/home/maxi/projects/django/django/django/db/models/sql/
> > compiler.py", line 735, in execute_sql
> > cursor.execute(sql, params)
> > File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> > django-firebird/firebird/base.py", line 231, in execute
> > return self.cursor.execute(cquery, params)
> > DatabaseError: (-530, u'isc_dsql_execute: \n violation of FOREIGN KEY
> > constraint "CONTACT_ID_REFS_ID_48084965" on table
> > "AGGREGATION_BOOK"\n Foreign key reference target does not exist --
> > INSERT INTO "AGGREGATION_BOOK" ("ID", "ISBN", "NAME", "PAGES",
> > "RATING", "PRICE", "CONTACT_ID", "PUBLISHER_ID", "PUBDATE") VALUES (1,
> > 159059725, The Definitive Guide to Django: Web Development Done Right,
> > 447, 4.5, 30.00, 1, 1, 2007-12-06)')
>
> > Here, the problem seems to be what is trying to insert
> > aggregation.book contact_id (which refers to Author model) before to
> > insert aggregation.author.
>
> > In initial_data.json aggregation.author data come after to
> > aggregation.book which violate the referencial integrity.
>
> > Is it an error or I'm doing something wrong?
>
> > Thanks for you help.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> This problem looks similar to one we see under MySQL InnoDB becaue it
> doesn't properly support deferred constraints.
>
Hi Alex,
Yes, that seems to be the problem. Firebird doesn't support deferred
constraints.
Are there any approach or workaround to solve this ?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
On Friday, March 25, 2011 11:43:39 PM UTC+11, Pascal Germroth wrote: > > On Fri, 2011-03-25 at 12:55 +0100, Łukasz Rekucki wrote: > > On 25 March 2011 12:34, Thomas Guettler wrote: > > > I look at your example code. You need to name the webserver in the > > > code. That's not very nice. I guess it should be possible to > > > guess the webserver (apache vs nginx) by looking at request.META. > > > > > > > -1 on guessing anything, especially something that doesn't change. > > Also, a fairly common configuration is Apache behind an nginx proxy. > > In this setup, I want nginx will be the one serving static files, not > > Apache. > > Why guess in the first place? Apache and Nginx both support 'X-Sendfile: > ' don't they? (older nginx seemed to only support their > own syntax, though). > Apache requires a separate module to be installed which isn't part of the core, so no you can't rely on it being present. Graham -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On Fri, Mar 25, 2011 at 6:45 PM, maxi wrote: > Yes, that seems to be the problem. Firebird doesn't support deferred > constraints. > Are there any approach or workaround to solve this ? No workarounds, no. We need to refactor our test suite to not rely on deferred constraints (except of course where we're actually testing deferred constraints, and there we need to skip those tests on less intelligent DBs). Most of the time we should just be able to rewrite our test data to not require forward references; where we can't we need to switch out fixtures for setup/teardown methods. Is there a ticket open to track this task? If not I'll open one. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On Fri, Mar 25, 2011 at 11:41 PM, Jacob Kaplan-Moss wrote: > On Fri, Mar 25, 2011 at 6:45 PM, maxi wrote: > > Yes, that seems to be the problem. Firebird doesn't support deferred > > constraints. > > Are there any approach or workaround to solve this ? > > No workarounds, no. We need to refactor our test suite to not rely on > deferred constraints (except of course where we're actually testing > deferred constraints, and there we need to skip those tests on less > intelligent DBs). Most of the time we should just be able to rewrite > our test data to not require forward references; where we can't we > need to switch out fixtures for setup/teardown methods. > > Is there a ticket open to track this task? If not I'll open one. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > There's http://code.djangoproject.com/ticket/3615, most of the effort there has been on making MySQL not be stupid though :) Someone at PyCon told me they found a way to make it work though (Chris Adams I think?). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.3: running test suit
On Fri, Mar 25, 2011 at 10:43 PM, Alex Gaynor wrote: > There's http://code.djangoproject.com/ticket/3615, most of the effort there > has been on making MySQL not be stupid though :) Someone at PyCon told me > they found a way to make it work though (Chris Adams I think?). I dunno -- almost everywhere I've seen we're using a forward reference it's just because we're lazy. As we've seen, there are other DBs besides MySQL that won't support forward refs. I'd like to just excise the use from the test suite or turn it into a setup/teardown. Just seems more robust against future expansion or whatever. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
