Re: Alternate ForeignKey based on choices
What you're wanting is a GenericForeignKey. Check out the
django.contrib.contenttypes documentation.
On Oct 26, 9:48 am, "Calvin Spealman" <[EMAIL PROTECTED]> wrote:
> You could also have a common parent class for Robot and User, and use that
> as your foreign key type. Which type is referenced would be your
> determination of user type.
>
>
>
> On Sun, Oct 26, 2008 at 6:19 AM, CooLMaN <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > I have an application with a model similar to the following:
> > class Relations(models.Model):
> > user1 = models.ForeignKey(User, related_name='relations_user1_set',
> > editable=False)
> > user2 = models.ForeignKey(User, related_name='relations_user2_set',
> > editable=False)
> > userType = models.PositiveSmallIntegerField(max_length=1,
> > editable=False, choices=( ('0', 'user'), ('0', robot) ))
>
> > Ok, so basically what I need this to do is that in case that the
> > userType is 1-robot it'll be a ForeignKey to Robot and not to User.
>
> > I'm assuming this is not possible with the current ORM implementation,
> > but I would be glad to hear I'm wrong.
>
> > Any suggestions? (this table serves the same purpose, and I'll most
> > likely always grab both robots and users so having another table for
> > each type is redundant and will be a problem if I append any more
> > choices in the future).
>
> > Thank you!
> > Gil
>
> --
> Read my blog! I depend on your acceptance of my opinion! I am
> interesting!http://techblog.ironfroggy.com/
> Follow me if you're into that sort of thing:http://www.twitter.com/ironfroggy
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Denormalisation Magic, Round Two
On Mon, Oct 27, 2008 at 8:05 AM, Andrew Godwin <[EMAIL PROTECTED]> wrote:
>
> class User(models.Model):
>username = models.CharField(max_length=255)
>email = models.TextField()
>num_photos = models.AggregateField("Photo", "fk:user", "count")
>num_all_photos = models.AggregateField("Photo", "all:", "count")
>
>def __unicode__(self):
>return "%s <%s>" % (self.username, self.email)
>
> class Photo(models.Model):
>caption = models.TextField()
>user = models.ForeignKey(User, related_name="photos")
>user_username = models.MirrorField("user", "username")
>
>def __unicode__(self):
>return "%s by %s" % (self.caption, self.user_username)
>
...
> So, what does everyone think? Useful, or just too much of an edge case?
> Reasonable patch, or badly implemented?
First off, details and implementation notwithstanding, I'm +1 for
adding denormalization fields of this sort. Apologies for not getting
involved during the first pass of this discussion.
I do have a slight reservation regarding the API you are proposing.
The fields you have proposed (MirrorField and AggregateField) capture
the obvious use cases, but the syntax don't feel consistent with the
rest of the Django API. In particular, AggregateField seems to be
introducing a whole new query syntax that is completely independent of
the aggregation syntax that is due for inclusion in v1.1.
I would prefer to see a syntax that demonstrated slightly better
integration with the Django query syntax. If it isn't possible to use
QuerySet itself as a way to develop the underlying query, then I would
expect to see a syntax that at the very least retained the flavour of
the Django query syntax rather than inventing "fk:" style operators
that have no real analog.
MirrorField is essentially a query that returns a related object;
AggregateField is a query that returns an aggregate of related
objects. Looking longer term, this sort of approach also has the
potential to be integrated into database views, since defining a view
requires similar querying capabilities.
Unfortunately, I haven't given this enough thought to be able to
suggest an alternate syntax that will do the job. At this point, I
just know that I would rather avoid introducing 2 different syntaxes
for aggregates. I have a hazy vision in my head of the sort of thing
that I think could work; I'll try to get it to coalesce a little and
get back to you.
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
I wouldn't expect SQLite to do well in a multi-process environment. Concurrency is SQLite's weak point, which makes sense given its heritage as an embedded database. --Ned. http://nedbatchelder.com mrts wrote: > It seems that current DB lock management doesn't play nice with the > new Python 2.6 multiprocessing package and SQLite. See [1]. The same > error also popped up in Google search under mod_python [2]. > > I wasn't able to reproduce this with MySQL. > > [1] http://code.djangoproject.com/ticket/9409 > [2] > http://209.85.135.104/search?q=cache:kEMOo-HuvzgJ:www.rkblog.rk.edu.pl/w/p/django-nginx/+django+OperationalError:+database+is+locked > > > > > > -- Ned Batchelder, http://nedbatchelder.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation Magic, Round Two
Russell Keith-Magee wrote: > I do have a slight reservation regarding the API you are proposing. > The fields you have proposed (MirrorField and AggregateField) capture > the obvious use cases, but the syntax don't feel consistent with the > rest of the Django API. In particular, AggregateField seems to be > introducing a whole new query syntax that is completely independent of > the aggregation syntax that is due for inclusion in v1.1. > > I would prefer to see a syntax that demonstrated slightly better > integration with the Django query syntax. If it isn't possible to use > QuerySet itself as a way to develop the underlying query, then I would > expect to see a syntax that at the very least retained the flavour of > the Django query syntax rather than inventing "fk:" style operators > that have no real analog. > Indeed; I was far happier with the queryset syntax for AggregateField I originally proposed, but I couldn't get it to work - it just won't go inside class bodies without far, far too much hackery. The MirrorField API I like more; I have an alternate version where you simply pass it the model name and column name, but that then has issues if you have more than one FK to the same model. The AggregateField proposal is just that, and I really squirmed at the idea of "all:" and "fk:", but it got it working pretty quickly. One possibility for more clean integration is an approach more like querysets, so you could have something like photos_count = models.AggregateField(Photo.view.filter(user_self=True)) The main problem with anything like this (and indeed with my attempt to implement this with plain old querysets) is that, as a field, you exist only on a class, and so when you get a signal saying a model has been updated, it's somewhat difficult to determine which instances of yourself to update - you can't loop through them all testing, since that's hilariously inefficient. That's why I limited the querying to only fk: and all: types, since detecting these is far more efficient. I'd love to see any proposal for how Aggregates should look, as my current incarnation really isn't too django-ish. I personally like MirrorFields (now on their third name, more welcomed) as I have them now, but then I would, since I invented them for my own use... Andrew --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Template block for submit buttons in admin's change_form.html
I remember seeing a couple of places where some extra template blocks
could help with extending the admin (object-tools springs to mind).
What are the pro's and con's of adding a sprinkling of new blocks?
On Oct 25, 5:14 pm, suuntala <[EMAIL PROTECTED]> wrote:
> G'day all,
>
> After a quick search, it seems I am not the only one who has had
> problems changing the submit buttons on an item's change view in the
> admin application. Some people even use JavaScript for this. For me
> the problem is that I would just like to change the buttons but still
> use admin/change_form.html as the base for my template without having
> to rewrite the whole "content" block.
>
> So, my question is: would it be possible to put the submit buttons
> inside their own block? Maybe there aren't too many cases where this
> would be useful but I can't see how it could do any harm either. Or am
> I missing something here?
>
> Now admin/change_form.html has this:
>
> {% submit_row %}
>
> What if that would be changed to, for example:
>
> {% block submit_buttons %}{% submit_row %}{% endblock %}
>
> Mikko
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 21, 7:27 am, mrts <[EMAIL PROTECTED]> wrote:
> It seems that current DB lock management doesn't play nice with the
> new Python 2.6 multiprocessing package and SQLite. See [1]. The same
> error also popped up in Google search under mod_python [2].
As others have pointed out, this isn't an issue with Django. The
easiest solution is to make this error less common with a higher
timeout. In settings.py:
DATABASE_OPTIONS = {'timeout': 30}
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Implementing a pure RDF backend for Django
>> >> Does anyone have any advice for me before I head off into the >> suburban >> parks of Django for an initial implementation? Any caveats I should >> consider which might make a pure RDF backend unfeasible? > > I used OpenLink Virtuoso Triple Store (via their HTTP SPARQL binding) > with the python RDFLib library as a glue layer. For templating, I Yes, rdflib looks like a good choice...better than django-rdf IMO as it is not Django centric. Do you know of any performance comparisons between Virtuoso and other RDF stores, like Neo4J? I'm interested in Neo4J for portability reason [J2ME]. > devised a simple yet powerful Selector language, not as powerful as > Fresnel selectors though; in the background, the selectors were > "compiled" into more efficient SPARQL queries. This was implemented as > a filter and templatetags. I preferred to write the ontology in > something like Turtle format. I'm not familiar with Turtle so I will look into that. I've only used OWL and Jena in the past but I hope that Django on jython will let me pick the best from Java or Python for usage. > I did not integrate this with the admin or with the existing ORM. > However, I was able to get a good faceted browser going using mootools > in the frontend and a custom metadata layer. This allowed me to plugin > in any ontology (with little modification) and browse the triple store > with the faceted browser. Creating triples was also done as a > framework with some mootools code in the frontend, and in the backend, > a generic view. I'll take a look. The database wrapping looks straightforward but I'm not sure yet if integration with the admin will be so straightforward so pure custom views might be the way to go. Thanks! James --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> As others have pointed out, this isn't an issue with Django. The
> easiest solution is to make this error less common with a higher
> timeout. In settings.py:
>
> DATABASE_OPTIONS = {'timeout': 30}
Thanks Brian, increasing the timeout fixed the problem.
IMHO this should be documented, so I reopened
http://code.djangoproject.com/ticket/9409
and changed the component to Documentation.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 6:57 pm, mrts <[EMAIL PROTECTED]> wrote:
> On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> > As others have pointed out, this isn't an issue with Django. The
> > easiest solution is to make this error less common with a higher
> > timeout. In settings.py:
>
> > DATABASE_OPTIONS = {'timeout': 30}
>
> Thanks Brian, increasing the timeout fixed the problem.
>
> IMHO this should be documented, so I
> reopenedhttp://code.djangoproject.com/ticket/9409
> and changed the component to Documentation.
I've attached the explanation to
http://code.djangoproject.com/attachment/ticket/9409/database_is_locked_docs.diff
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 1:46 pm, mrts <[EMAIL PROTECTED]> wrote: > > IMHO this should be documented, so I > > reopenedhttp://code.djangoproject.com/ticket/9409 > > and changed the component to Documentation. > > I've attached the explanation > tohttp://code.djangoproject.com/attachment/ticket/9409/database_is_lock... I agree, and this explanation looks good. +1 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
> I agree, and this explanation looks good. +1 Its a bit deeper than that... but I'm waiting for my friend to respond (he worked on sqlite issues at my last company). Hopefully I'll hear from him today and be able to add some more details. -rob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 11:21 am, oggie rob <[EMAIL PROTECTED]> wrote: > Its a bit deeper than that... but I'm waiting for my friend to respond > (he worked on sqlite issues at my last company). Hopefully I'll hear > from him today and be able to add some more details. Okay, so I got the good word :) First off, I want to acknowledge the work that Ben Cottrell put into finding these issues. It seems like this is usually discovered only with a specific setup and it took a lot of time and effort for him to track down the issues. Essentially you'll need to use pysqlite 2.5.0 for this to work. Even increasing the timeouts won't "solve" the problem, they'll just allay them a little (and at some point you'll see the locks again). Certainly, there is a limit to how quickly transactions can get done with sqlite (and thus the timeout is still relevant), but I don't think you will want to rely on that. The reason pysqlite 2.5.0 works is due to the fix in changeset 337 (http://oss.itsystementwicklung.de/trac/pysqlite/changeset/ 337%3A80ee6488cb53). It is much more likely to be noticed if you're running in a multi-threaded environment (and from what I could determine, this is the reason it hasn't been more of an issue to the django community, given that sqlite is fairly widely used). Also, because django 'prefers' sqlite3 to pysqlite, you'll need to patch django/db/backends/sqlite3/base.py after you've installed it. (This change should probably be merged into trunk as it allows for installing the most recent version of pysqlite, as opposed to whatever sqlite3 you have in your python version. In other words, I think django should "prefer" pysqlite as a more intentional setup.) Finally, one issue we didn't really dig into but Ben did discover, is changing from a shared (i.e. "reading") to an exclusive (i.e. "writing") lock. Example: you're iterating through a queryset, and inside the same transaction you do some write operation, *and* you have threads colliding with each other (both trying to get an exclusive lock), you may see the db locked exception. A simple workaround for this is to force an evaluation on your iterating queryset (i.e. wrap it in list()), or run the write operations after you have finished the iteration. If this looks like a lot of work to get sqlite going, you might be right :) I hope that covers everything. I'm willing to update the ticket, but first do you think you could try the pysqlite fix that I suggested (and remove the timeout change to be certain that doesn't interfere)? I want to be sure that it solves it. -rob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: Year navigation in admin's date widgets' calendar
Hi all, I've opened a ticket on this topic: http://code.djangoproject.com/ticket/9388 Actually, the DateTimeShortcuts JavaScript object in django/contrib/admin/media/js/admin/DateTimeShortcuts.js has already got drawPreviousYear and drawNextYear methods, however admi's date widgets' calendar does not allow year navigation. In ticket above, I propose a patch. Best regards. <- versae -> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)
I'm not sure if this is 'supposed' to be the case or not so i'll ask
i think i've seen a similar post like this before, but either a) i'm
bad a search for it or b) it was only slightly related
--- the issue ---
using RequestContext(request, {}) + Auth.middleware always seems to
access the session the "get_user" from the auth/__init__.py and thus
prefills the user .. thus hitting both the Session (as Accessed) and
the User (if present in the form of a DB query).
even if the "user" is never used in the Templates or in the View
functions
this has one major (only major if you site sits behind SQUID or some
other proxy goodness) that it _always_ sets the Vary: Cookie Header ..
pretty much killing any cache-ability beyond those with no cookies
enabled (and in these days what site does toss some cookies in the mix
for tracking/sesssions that may be used later in the site, like
shopping carts, but not for every page)
Here is the backtrace to confirm
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
django/core/servers/basehttp.py", line 278, in run
self.result = application(self.environ, self.start_response)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/core/servers/basehttp.py", line 635, in __call__
return self.application(environ, start_response)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/core/handlers/wsgi.py", line 239, in __call__
response = self.get_response(request)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/core/handlers/base.py", line 86, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/Sites/testy/views.py", line 262, in test_view
out = RequestContext(request, {})
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/template/context.py", line 105, in __init__
self.update(processor(request))
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/core/context_processors.py", line 20, in auth
if hasattr(request, 'user'):
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/contrib/auth/middleware.py", line 5, in __get__
request._cached_user = get_user(request)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/contrib/auth/__init__.py", line 83, in get_user
user_id = request.session[SESSION_KEY]
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/contrib/sessions/backends/base.py", line 46, in
__getitem__
return self._session[key]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)
Actually i've found that the issue lies with the TEMPLATE_CONTEXT_PROCESSORS django.core.context_processors.auth which does the get_and_delete messages bit .. so i guess that is the proper behavior. Sad to say that although my app can work around that issue (by using a different messages mechanism thus i do not need django.core.context_processors.auth) but "contrib.admin" screams if it is not included. So either this may be a documentation issue to say that "using django.core.context_processors.auth will always insert a Vary: Cookie header" or fix up admin to use the "request.user" instead of "user" directly in the Context and then require "django.core.context_processors.request" to always be included ... bo --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
I just wanted to check if there was a consensus on this; it would be nice to get it into the Django 1.1 featureset. Regards, Zack --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)
This is exactly why my patch in the session messages ticket [1] makes the messages lazy. [1] http://code.djangoproject.com/ticket/4604 On Oct 28, 1:59 pm, bo <[EMAIL PROTECTED]> wrote: > Actually i've found that the issue lies with the > TEMPLATE_CONTEXT_PROCESSORS > > django.core.context_processors.auth > > which does the get_and_delete messages bit .. > > so i guess that is the proper behavior. > > Sad to say that although my app can work around that issue (by using a > different messages mechanism thus i do not need > django.core.context_processors.auth) but "contrib.admin" screams if it > is not included. > > So either this may be a documentation issue to say that "using > django.core.context_processors.auth will always insert a Vary: Cookie > header" or fix up admin to use the "request.user" instead of "user" > directly in the Context and then require > "django.core.context_processors.request" to always be included ... > > bo --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
