Re: Example on bitmap charts
On Sep 8, 2006, at 5:23 PM, Andy Robinson wrote: > I have just added a Wiki page under the Cookbook section showing > how to > create dynamic charts using ReportLab's graphics library. It seems > not > many people know about our chart library, which has been serving > financial charts in big firms for years. In any event the Django > integration is trivial. Thanks, Andy! You can add me to the list of people who until now didn't know about the graphics library; I've used ReportLab for PDF generation for years without noticing this corner of the library. Thanks again for the example, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Custom default managers interfere with delete operations
On 9/9/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Thinking a little higher level, it feels like we should be avoiding the idea > of a 'default' manager as much as possible. We let people define multiple > managers, but we fall back to the default far too often. Agreed; there are a couple of tickets out for situations where we inappropriately fall back to the model's default manager, and those situations aren't all that uncommon. What's worse, it means you sometimes end up in a situation with no good solution, because no matter how you set up your managers there's something that won't work the way you'd expect it to. For example (taken from a real-world app I've worked on)... Consider a weblog app with an Entry model and a Category model: * An Entry can be either "live" or "draft". * There's a many-to-many relation between Entry and Category. Now, the obvious thing to do is set up a custom manager which only returns "live" entries. Since for most purposes that's what we want, we make it the default manager. Then, to keep things working in the admin, we add a vanilla instance of models.Manager, and tell the admin to use that instead of the default manager. Except this doesn't work; the manager we've specified for the admin to use will only actually be used on change lists; editing an object uses the model's default ChangeManipulator which, of course, uses the model's default manager. Se we end up with objects that we can see in the change list, but not edit (this is ticket #1855). But if we switch the order of manager around so that the "vanilla" one becomes the default (which restores the ability to edit all entries in the admin), now we run into problems with the Entry-Category relation; when we have a Category and want to fetch related Entry instances, the many-to-many descriptor uses the default manager for Entry and doesn't (so far as I know) offer any way to change that. So we end up getting all entries, not just "live" ones. Since the latter can be worked around by writing custom methods on the Category model which duplicate the filtering logic of the custom manager on Entry, that's what I ended up doing, but that's only marginally less ugly than not having the functionality a custom manager should be able to provide. It'd be awfully nice not to end up in those sorts of "no-win" situations... -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Custom default managers interfere with delete operations
> Consider a weblog app with an Entry model and a Category model: > > * An Entry can be either "live" or "draft". > * There's a many-to-many relation between Entry and Category. [snip (paraphrased) altering the default manager breaks admin, but it's necessary to change how related fields do their lookups] > It'd be awfully nice not to end up in those sorts of "no-win" situations... Would it make any sense to allow relations to specify the manager they should use? For instance: class Category(models.Model): # ... entries = ManyToManyField(Entry, manager='live_entries') Or rework relations to allow relations to other *managers* instead of other *models*: class Category(models.Model): # ... all_entries = ManyToManyField(Entry.objects) entries = ManyToManyField(Entry.live_entries) SQLAlchemy does something similar to the 2nd example, in that relations are related to mappers not mapped classes. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Custom default managers interfere with delete operations
Russell Keith-Magee wrote: On 9/9/06, Ned Batchelder <[EMAIL PROTECTED] > wrote: I'm not familiar with the internals of this code, but here's a naive conception: since the default objects manager is made automatically by the ORM, couldn't it still be available internally for use in this case? Whatever filtering is done by the app developer's default manager, it has to be defeated in order to properly delete related objects. So why not skip the developer's default manager and use the default default manager (if you know what I mean). This approach sounds possible. My lingering concern is that there might be situations where using the user defined manager would be the correct behaviour for the object deletion algorithm. Your example is a bit of a weird case, born of the collision of two methods of 'deleting' objects (your boolean field representation and Django's database level deletion). I'm not entirely convinced that fixing the problem for your (somewhat specialised) use case wouldn't break it for all other legitimate uses. The details of my specific case are a bit of a red herring. The fact remains that if the default manager does any filtering at all, then deleting an object may fail because its related objects will not all be deleted, and the database's referential integrity will prevent the deletion. When looking for related obejcts to delete, you have to always get all of them. No filtering allowed. -- 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 -~--~~~~--~~--~--~---
log_action & message rendering
Is there a special reason to put message rendering out of log_action and LogEntry context ? Usually, logger or renderer does it, probably delegating call to object. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
