Putting content_type on a different class for a generic relation?
I've got two models. Here's what I'm trying to do:
class InterestSet(models.Model, MailChimpAPIMixin):
name = models.CharField(help_text="The interest grouping to add.
Grouping names must be unique.", max_length=128, unique=True)
content_type = models.ForeignKey(ContentType, blank=True,
null=True)
class InterestGroup(models.Model, MailChimpAPIMixin):
name = models.CharField(max_length=128, unique=True)
interest_grouping = models.ForeignKey(InterestGrouping)
object_id = models.PositiveIntegerField(blank=True, null=True)
content_object =
generic.GenericForeignKey('interest_set__content_type', 'object_id')
Basically, I want to define a content type for an Interest Set on the
"parent" model. Then, for each Interest Group, I want the object id to
always refer to the content type set on Interest Set. You can see by
the first argument to GenericForeignKey() how I wish it worked.
Alas it does not. Plan B is just to move the content_type field back
to Interest Grouping and deal (or possibly just custom code my
relationships without relying on GenericForeignKey). It's a shame
because it duplicates data unnecessarily and creates an opportunity
for a relationship to be created that violates a business rule for
this application (which is that all Interest Groups in an Interest Set
must be related to the same content type).
I'm just wondering if either a) I'm missing an obvious way to
accomplish this or b) this has come up before or been discussed
somewhere. I might explore the possibility of patching the source code
to enable this behavior of that sounds at all desirable.
Let me know your thoughts. Thanks.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Does loaddata in fact save objects to DB with a raw save? Or is this a bug?
> loaddata saves object created via deserialization, which pass raw=True to > the model's save_base, see: > > http://code.djangoproject.com/browser/django/trunk/django/core/serial... Thanks Karen. That's exactly the answer I was looking for. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Does loaddata in fact save objects to DB with a raw save? Or is this a bug?
I was just now researching some options for how to manage the way certain post_save/pre_save signals can interfere with fixture loading during tests, when I happened upon this ticket: http://code.djangoproject.com/ticket/12610 Which says: "There is already a hook to check for this - data saved during a fixture load is loaded 'raw', and the 'raw' argument is passed to the pre/post save handlers. If you modify your pre/post save handlers to do nothing in the case of a raw save, you should be able to load fixtures without the problems you describe." It made sense to me, but when I why tried to actually use it...I found raw was not being passed at all to any of my handlers. Closer examination of loaddata.py does not show it using save_base() or passing raw anywhere. So that leaves me confused. Am I overlooking something? Or is comment by Russel in the ticket wrong? I might do a bit more research. I imagine there must be a test or other open ticket specifying the raw behavior, and if so that could be broken, in which case I'll file a ticket. I figured I'd post here first before raising the alarm. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Preventing code from running during user tests
Thanks Russ, that's helpful. I would think signals would ideally be a solution for this, no? E.g., a setup and teardown signal that fired in setup_test_environment() and teardown_test_environment(), respectfully. I was actually hoping to find this already implemented when I checked the documentation for signals. On Sep 16, 5:13 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Sep 17, 2010 at 6:15 AM, Jim D. <jim.dal...@gmail.com> wrote: > > I have some code that calls a third-party API in a Django application > > I'm working on, which could be triggered at various points throughout > > a project. I would like to ensure that the API itself doesn't actually > > get called at all during test mode, much the same way that Django > > itself swaps out the email backend during test mode to ensure emails > > don't actually get sent during testing. > > > The key point here is I need to ensure the real library isn't being > > called anywhere during the tests being run throughout the suite, not > > just in the test code I'm writing specifically for the application > > itself. > > > Is there a clean way to do this? I notice that Django disables the > > email and a few other settings in the setup_test_environment() > > function. I'd like to do something similar, but the only idea I've > > come up with so far is to create a custom test runner that extends the > > default setup_test_environment() method and adds a few items of my > > own. While this would work, it would depend on the project using a > > custom test runner. > > > Other ideas include a crazy hack like this guy has proposed: > >http://www.thebitguru.com/blog/view/246-Using%20custom%20settings%20i... > > > Surely others of you have had to ensure a given library isn't called > > during testing or development (e.g. if you were implementing a payment > > processor API, you wouldn't want to actually call that library during > > tests). Am I just missing a totally obvious way to accomplish this? > > A custom test runner would be the usual way to accomplish this, and as > of Django 1.2, it's a lot easier to write one because the test runner > is class based. On a smaller scale, you could also accomplish this > using a setUp()/tearDown() pair in individual test cases. > > The "if TEST" approach advocated by 'thebitguru' will certainly work, > but it's not a pattern that I'd like to see take hold in Django > itself. This approach essentially introduces branches into your main > codebase, so now you need to be testing whether or not your code is > hitting the right branches -- in theory, it is possible that your > production code could activate the "if TEST' branch, so you need to > test that this won't happen. > > If you have a suggestion of a better way to provide setup/teardown > hooks, I'd be happy to hear it. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Preventing code from running during user tests
I have some code that calls a third-party API in a Django application I'm working on, which could be triggered at various points throughout a project. I would like to ensure that the API itself doesn't actually get called at all during test mode, much the same way that Django itself swaps out the email backend during test mode to ensure emails don't actually get sent during testing. The key point here is I need to ensure the real library isn't being called anywhere during the tests being run throughout the suite, not just in the test code I'm writing specifically for the application itself. Is there a clean way to do this? I notice that Django disables the email and a few other settings in the setup_test_environment() function. I'd like to do something similar, but the only idea I've come up with so far is to create a custom test runner that extends the default setup_test_environment() method and adds a few items of my own. While this would work, it would depend on the project using a custom test runner. Other ideas include a crazy hack like this guy has proposed: http://www.thebitguru.com/blog/view/246-Using%20custom%20settings%20in%20django%20tests Surely others of you have had to ensure a given library isn't called during testing or development (e.g. if you were implementing a payment processor API, you wouldn't want to actually call that library during tests). Am I just missing a totally obvious way to accomplish this? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Admin widget for large number of related records
I apologize if this question has been asked/answered here before, but I searched around and couldn't find anything. We're working on a django app in which we're porting some existing user data overwe have about 100,000 user records that are being imported. We have many other models that are linked back to User in a one-to-many association. The problem we're experiencing is with the admin. When we're displaying the admin edit form for a model that's related to User, it ends up with a drop down allowing you to change which user is associated with the object. The problem is that 100,000 user records end up appearing in this drop down! Is there a different widget that can be used in the case where an object is related to another with a really large number of records? Or are we doing something wrong that I'm overlooking? I feel like this must have come up for many people and I must be missing something that's super obvious to everyone else. Any advice or guidance you guys can provide is very much appreciated. Many thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Custom template tag problem: "No module named models"
I came across this thread and was having the exact same problem. *Exactly* the same... I had tried everything you tried to no avail. I actually fixed it by taking a hint from something that came out of following along with your debug session in my own code. I'll put my solution in terms of your code. This fails: from django import template from django.contrib.contenttypes.models import ContentType from bookmarks.models import Bookmark This works: from django import template from django.contrib.contenttypes.models import ContentType import bookmarks from bookmarks.models import Bookmark I'm not quite sure why though. I wonder, did your solution end up looking anything like the above? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to know which fields a model contains?
I'm pretty new to python myself, but my favorite way to inspect objects that I have found so far is the builtin method dir(). As in: dir(Publisher.objects.get(pk=1)) dir() tells you all of the methods and attributes for a given object, though it doesn't display the value of attributes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Issue with serializing a queryset that includes a custom SQL field defined by extra()
I think this might be a bug in source code, but before I report a
ticket I thought I would ask just to ensure it's not me doing
something wrong/stupid.
In brief, I have a (MySQL) database table containing latitude and
longitude columns. I am finding records from this table and sorting
them based on distance, and to do this I'm adding a custom column in
the select statement using the extra() QuerySet function.
So here's the relevant code for this part:
entries = Entry.objects.filter(type='country')
entries = entries.extra(select={'distance': "SQRT(POW((locations.lat-
%s),2) + POW((locations.lon-%s),2))"}, select_params=(str(centerLat),
str(centerLng)))
entries = entries.extra(order_by = ['distance'])[:100]
In a nutshell, this code defines a custom column "distance" and uses
some MySQL numeric functions to calculate a hypotenuse to get the
distance value. The result set is ordered by this column. This works
great.
Now for the issue...when I serialize this code as follows:
from django.core import serializers
json_serializer = serializers.get_serializer("json")()
json_serializer.serialize(entries, ensure_ascii=False,
stream=response, fields=('title','lat','lon','distance'))
The problem being that the "distance" column does not end up getting
included in the json output. The other columns are included, however,
no problem.
I have even inspected the queryset in entries an confirmed that each
object does in fact contain a distance attribute, as a float, which is
set properly.
Sofinally to my question...is there an issue of some kind with the
way the serializer handles extra fields, or am i just doing it wrong?
FYI i'm on the latest release Django version 1.0-beta_1-SVN-8539.
Thanks for any help or suggestions you guys can provide!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
