Re: Model inheritance API
Malcolm Tredinnick wrote: > Rather than watch the "inherit from User" thread go round and round, > maybe I should give people something more concrete to think about. > > This is a follow-up to the mail I sent late on Friday. It describes the > area where we need API additions or some kind of semi-major change to > incorporate model inheritance and some developer feedback would be a > good idea. I am only talking about the API here, not the implementation > (since you will notice there is no patch attached to the email). > > Model inheritance (as I've implemented it) comes in two varieties, > differentiated by the way they store the data at the db level and by the > way you use them at the Python level. > > --- > 1. Abstract Base class > --- +1e6 Great!!! Just when I need it - I'm going through pain of maintaining four separate models with lot's of common fields. Go for it. > --- > 2. "Pythonic" Inheritance > +1 even better (I'm not in any way database and/or django ORM expert so I will not comment actual implementation). -- Nebojša Đorđević - nesh Studio Quattro - Niš - SCG http://studioquattro.biz/ http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Absence of CheckboxField validation
Hi there, Is there a reason why CheckboxField(and model's BooleanField) doesn't have validator_list ? We discussed briefly this issue on irc and seems like its just because of lack of use cases for validation ? In my case i need to check other field's value and only if it has specific value allow CheckboxField to be True. And in a whole, without validation it looks not so consistent with other Fields, even if it has such seldom used validation cases. There is already ticket #1767 with the patch, submitted 3 months ago, followed by silence. With best regards, Alex --~--~-~--~~~---~--~~ 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: Model inheritance API
Malcolm Tredinnick wrote: > On Sun, 2006-07-23 at 17:12 +0100, Bill de hÓra wrote: > > Malcolm Tredinnick wrote: > > > --- > > > 3. What you don't get > > > --- > > > [...] > > > I am not implementing the "everything in one table" storage model. It is > > > not universally applicable (you can't inherit from third-party models, > > > for a start) and I have software engineering objections to it. > > > > Why? NOT NULL constraints in the children? > > That's one good reason. It's also not very normalised; table design with > lots of sparse columns won't get me invited to the cool parties. Wide > rows where you only need to access a few fields tend to not always > perform as well as people might like (I'm talking about very large > datasets here; small datasets don't matter so much). > > Finally, because I would like to support extending third-party models > out of the box, we need the multi-table model and I don't want/need the > extra complexity of more and more alternatives right now. That's > something somebody could add later if their continued existence depended > on it. It's all "under the covers" work. > > I'm on a "pick one thing, do it well" drive at the moment (with a slight > concession to the abstract base class case). The big downside to one table to hold all data would be that if I ever added a new derived class, I need to rebuild the table for _all_ other classes. Unless you pair this with schema evolution, that would seem to be a showstopper. -Dave --~--~-~--~~~---~--~~ 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: Model inheritance API
Malcolm Tredinnick wrote: > table design with > lots of sparse columns won't get me invited to the cool parties. Qotd! [I should say what you're doing sounds great; just trying to figure out where the constraints and gotchas are at.] cheers Bill --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RFC: Localization (L10N)
sorry for cross post. I just want to bring some attention to this thread http://groups.google.com/group/Django-I18N/browse_thread/thread/f33c087fc57fb2bc/44aecc7ee75f676f#44aecc7ee75f676f We currently have great i18n implementation, but not l10n - yes, we have date-aware template filters/tags but this is far from complete - no locale aware number formating for example. Comments? (please reply in i18n group) -- Nebojša Đorđević - nesh Studio Quattro - Niš - SCG http://studioquattro.biz/ http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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: Model inheritance API
Bill de hÓra wrote: > Malcolm Tredinnick wrote: > >> table design with >> lots of sparse columns won't get me invited to the cool parties. > > Qotd! > (added to my quotes-collection :-) gabor --~--~-~--~~~---~--~~ 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: MS SQL Server access from Linux/ODBC?
Have you considered migrating the data from MSSQL to Postgres? We ran into the same problem you are having, and purchased the "DTM Migration Kit". http://www.sqledit.com/mk/index.html This tool lets you do arbitrary sql on migration, so if the MSSQL database is being used by another app, you can leave unessesary stuff behind (we left credit card numbers behind...a big advantage). --~--~-~--~~~---~--~~ 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: Creating a new field type
Jacob Kaplan-Moss wrote: > > A good example might be to look at the ``DateField`` definition > (http://code.djangoproject.com/browser/django/trunk/django/db/models/ > fields/__init__.py#L393). > > As far as I remember, the methods you'll want to play with are > ``Field.to_python()``, ``Field.get_db_prep_lookup()``, and > ``Field.get_db_prep_save()``. Thanks! I've got that part all sorted out now. However, I'm running into an issue with FormFields and their html2python() method. According to the docstring for Manipulator.do_html2python: "html2python functions aren't expected to deal with invalid input." Taking this as gospel, I put a validator in the form-field's validator_list, which raises a ValidationError if the data is not valid. When testing via the admin interface with invalid data, I was surprised to find that html2python() was still called! The code there (decimal.Decimal() in fact) raised an InvalidOperation exception that I hadn't bothered catching, as I was assuming that the data would be valid by that point. Digging into the calling code, I found in FormField (forms/__init__.py, line 94 or thereabouts): def convert_post_data(self, new_data): name = self.get_member_name() if new_data.has_key(self.field_name): d = new_data.getlist(self.field_name) try: converted_data = [self.__class__.html2python(data) for data in d] except ValueError: converted_data = d convert_post_data() is called by Manipulator.do_html2python(): def do_html2python(self, new_data): """ Convert the data from HTML data types to Python datatypes, changing the object in place. This happens after validation but before storage. This must happen after validation because html2python functions aren't expected to deal with invalid input. """ for field in self.fields: field.convert_post_data(new_data) And that in turn was called from contrib/admin/views/main.py, in add_stage() (line 244): if request.POST: new_data = request.POST.copy() if opts.has_field_type(models.FileField): new_data.update(request.FILES) errors = manipulator.get_validation_errors(new_data) manipulator.do_html2python(new_data) if not errors: new_object = manipulator.save(new_data) The answer to my immediate problems is clearly just to catch InvalidOperation and raise ValueError instead; but this question/issue remains: FormField.convert_post_data() in collusion with Manipulator.do_html2python() is clearly NOT following the guideline laid out in the docstring to the latter -- it doesn't check whether the data is valid (or has been validated), but calls html2python() and expects it to raise ValueError if the data is not valid. Moreover, the docstring to Manipulator.do_html2python() appears to be making this guarantee which Manipulator CANNOT keep: because it relies on its callers to call get_validation_errors(), and then to call do_html2python() only if there were no errors. Of the five places in the django source where this is called -- contrib/admin/views/main.py: add_stage(), contrib/comments/views/comments.py: post_comment() and post_free_comment(), and views/generic/create_update.py: create_object() and update_object() -- only the ones in comments are checking for errors before calling do_html2python(). I'm not sure what the solution to this is (save for updating the docstring to reflect what the code does instead of what it was presumably intended to do at some point); and I'm not even sure that there is a good solution with the current Manipulator shamozzle. --~--~-~--~~~---~--~~ 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: Creating a new field type
One other side effect of the problem noted in my message above is this: If I enter "1e5" in the text field, it fails validation (as I'm limiting it to -?\d+(\.\d+)? ), but the new_data entry still gets converted to a Decimal instance, so the form displays an error message but the data in the box has been changed to "1E+5". To avoid this, I'd need to validate the data again in html2python(), which is not DRY. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Strange happenings with fkey-linked models and AddManipulator
Hi there, I'm getting some very odd behaviour when trying to use unique_together, foreign keys, and AddManipulator() all together on some of my models. http://rafb.net/paste/results/kIEaT886.html - Company model http://rafb.net/paste/results/V3XUxE96.html - Notes model These are the models I'm using for this. In the first case, trying to use AddManipulator() on the Company model, I get the following traceback: http://rafb.net/paste/results/H7KQX420.html Removing unique_together from the Notes model stops this error from triggering. In the second case, while calling AddManipulator() on Notes itself, the following error and traceback are created: http://rafb.net/paste/results/C80bHe44.html In this case, removing the self-referential fkey causes the bug to no longer trigger. Any thoughts/advice? --~--~-~--~~~---~--~~ 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: Strange happenings with fkey-linked models and AddManipulator
Hi Aurynn, Aurynn wrote: > Hi there, I'm getting some very odd behaviour when trying to use > unique_together, foreign keys, and AddManipulator() all together on > some of my models. > > http://rafb.net/paste/results/kIEaT886.html - Company model > http://rafb.net/paste/results/V3XUxE96.html - Notes model > > These are the models I'm using for this. > > In the first case, trying to use AddManipulator() on the Company model, > I get the following traceback: > http://rafb.net/paste/results/H7KQX420.html > > Removing unique_together from the Notes model stops this error from > triggering. > > In the second case, while calling AddManipulator() on Notes itself, the > following error and traceback are created: > > http://rafb.net/paste/results/C80bHe44.html > > In this case, removing the self-referential fkey causes the bug to no > longer trigger. > > Any thoughts/advice? About the second case: What strikes me first: Wouldn't this need a related_name? Are you up to date on svn? If this doesn't help, see ticket 1839. Renaming the field 'note' should help Probably, this is more a question for the user list. Best regards, Michael --~--~-~--~~~---~--~~ 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: Model inheritance API
Jacob Kaplan-Moss wrote: > On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote: > > Rather than watch the "inherit from User" thread go round and round, > > maybe I should give people something more concrete to think about. First of all, +1 on this proposal. I've been approaching this problem from different ways for the past couple of weeks, and had settled on a very similar one to implement myself. I was suffering from a lack of examples of how to use the content type app though. > > (2) Any strong reason not to include this case? It's only for > > "advanced > > use", since there are a few ways to shoot yourself in the foot (e.g. > > declare a class abstract, create the tables, remove the abstract > > declaration, watch code explode). However, it will be useful in some > > cases. [I have some scripts to help with converting non-abstract > > inheritance to abstract and vice-versa at the database level, too.] > > I think abstract base classes are *key*, actually -- nearly every use > I'm thinking of includes 'em. . . . > So I'd get back an iterator that yields Things, Animals, and Toys? > That's what I'd expect, and want. I also think keeping the abstract class as a way of aggregating all the subclasses is key. An iterator is exactly what I would like to see as well. Please post any examples / code as they come! David Blewett --~--~-~--~~~---~--~~ 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: [Django] #2406: [patch] new command for management -- runjobs
Adrian Holovaty wrote: > If your goal is to cut crontab entries from five to one, just create a > single script that does the five things you need it to do; then point > crontab at it. :) But it would be fine for pluggable applications to make this automatically! (I'm +1) Michael --~--~-~--~~~---~--~~ 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: Strange happenings with fkey-linked models and AddManipulator
On 7/24/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > Probably, this is more a question for the user list. Actually, after around sixteen hours of off and on fiddling with things via IRC, I suggested she ticket it and post here to see if any of the rapid-fire Django bug squashing team at OSCON could take a look at it :) -- "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: humanized dates
> functionality in django.utils.dateformat introduces some other Well, consider that under-documented. It's not clear how to do that as a filter in the Template Guide. I'll agree that it's outside the scope of 'humanize'. --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
Don't mean to pester but is there a way for me to post the list on the wiki? Like I said, I think I'm blocked now. :( Cheers, Chris --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
On 7/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Don't mean to pester but is there a way for me to post the list on the > wiki? Like I said, I think I'm blocked now. :( Ouch, I'm sorry. :-( I'm sure Jacob meant to get back to you, but I know he's been insanely busy with preparations for OSCON (which he's attending at the moment). I'll bug him again for you. :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
after save() hook not called in admin?
Sorry if this has been mentioned but I couldn't find any reference to it. Anyway, there seems to be an issue with custom save() hooks and the admin interface. When called from the shell .save() works as expected, executing code both before and after the call to super(). However, in the admin, it appears that only code before the call to super() is actually being called. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
