Re: can I mimic authenticated user from shell?
Now's a good time to try the new testing framework's test client http://www.djangoproject.com/documentation/testing/#test-client login as whomever, send some URLs, check the results. I know it ain't quite what you're looking for, but it may help. --~--~-~--~~~---~--~~ 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: {% url %} syntax, and its equiv in python?
On Mar 5, 6:45 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Hmm ... for consistency's sake, we should change that. We do seem to be > pretty much always resolving unquoted tokens as variables in the current > context. The only real exception I can find is the "ssi" tag (you have > to gloss over unusually-shaped tags like "for", too). > > Can you file a ticket, please? #3668 now open for business > Maybe what you are looking for, though, is the permalink() decorator for > models or the django.core.urlresolvers.reverse() function. Thanks, those will help. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
{% url %} syntax, and its equiv in python?
I'm building up menus in django, and wanted a construct like this:
{% for item in menu %}
{{item.label}}
but that doesn't work, because there's no view "item.view"
so point 1, looks like a shortcoming in the syntax of the URL tag.
With most tags, an unquoted item gets looked up, and a quoted item is
used as-is. Here, there's no way to look up the first argument to URL.
Second item, I seem to remember there being an older/stable URL
reverse-lookup function exposed to us from some module, but I can't
find a reference to it/docs at the moment! Or am I confused, and
should just import the template tag, use that in my code?
thanks for help!
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
URL extra options placeholder syntax- or is it only for generic views?
http://www.djangoproject.com/documentation/generic_views/ has this
example:
... redirects from /foo// to /bar//:
urlpatterns = patterns('django.views.generic.simple',
('^foo/(?P\d+)/$', 'redirect_to', {'url': '/bar/%(id)s/'}),
)
What replaces the '%(id)s' section, the generic view package, or the
URL dispatcher? Is there more documentation on this?
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: Using django for CMS stuff
On Feb 14, 12:12 pm, "walterbyrd" <[EMAIL PROTECTED]> wrote: > CMSes like joomla and drupal have a rich assortment of plugins/modules/ > extensions for stuff like: blogs, forums, galleries, news aggregators, > ecommerce, document management, and so on. > > How difficult would it be to get that sort of functionallity from > dango? You can't download many of those, at least in polished form, though you can write any of them. You also can say the same about any web framework: Turbogears, Pylons, Rails, Catalyst... You'll probably want object-level permissions, and using the Django branch for that would be helpful for all. But Django (and Turbogears, Pylons, Rails, Catalyst...) are not like Joomla and Drupal- the former make it easier to write web apps, the latter are web apps. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Selecting MySQL engine (InnoDB/MyISAM) when creating models
There's a thread from June 28 '06 on this list about changing MySQL's storage engine from InnoDB to MyISAM for a particular table/model. Now, an InnoDB table respects foreign keys, and a MyISAM table ignores them. An "ALTER TABLE ... ENGINE = MyISAM" statement will fail if the table has any foreign keys defined. On the other hand, a "CREATE TABLE ... ENGINE = MyISAM" statement with foriegn key definitions works, silently ignoring the foreign keys. Subsequent "ALTER TABLE ... ADD CONSTRSAINT ... FOREIGN KEY..." are also silently ignored. So it seems here's a case where some extension to let the django app writer modify the "CREATE" sql would be very handy. I don't suppose anyone has a patch ready for it?http://code.djangoproject.com/ticket/ 347 implies such a thing would be frowned upon, but I'd rather have an unsupported patch then have to abandon "manage.py test" due to SQL errors... if not, I believe the shortest path would be a "pre_db_table" signal, which I should be able to whip up quickly. I suppose one could drop the foreign key constraints before altering the table, but it looks like they're named with some random characters in it. So one would have to look at the metadata, get the FK constraint name, and use that in generating the SQL: ugly, and more a job for Python, not the SQL that gets run by syncdb... What to do... (and I can't set the default storage type, since the app's deployed to a remote host, where we don't have access to the MySQL setup) --~--~-~--~~~---~--~~ 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: ForeignKey, null, and schema evolution
IIRC, Django's admin can't handle a field with null=True and blank=False (which is a bit of a shame...) Try adding blank=True to your model's field? --~--~-~--~~~---~--~~ 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: ForeignKey model vs. Foreign Key database
Feb 7, 3:03 pm, "yary" <[EMAIL PROTECTED]> wrote: > ... If I could get some guidance as to writing the test > (as mentioned in the 2nd half of my original message) I'd me much > obliged, and will get to work on patching #2720. I think I can figure it out, will ping back if I have a more specific question. --~--~-~--~~~---~--~~ 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: ForeignKey model vs. Foreign Key database
Thanks for the ref. That patch doesn't address the problem of a ManyToMany field referring to not-yet-created tables, and the patch breaks my project. If I could get some guidance as to writing the test (as mentioned in the 2nd half of my original message) I'd me much obliged, and will get to work on patching #2720. --~--~-~--~~~---~--~~ 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: Newbie: is it possible to use Django's db API outside of Django?
On Feb 7, 1:22 pm, [EMAIL PROTECTED] wrote: > Thanks for the link! > Would I really have to set up my backend app as a Django App? > Is it required to due to some meta-programming magic? > ie I'd rather not have to run our app via manage.py/django-admin. let me see if I understand your situation- you want to replace the frontend entirely, and keep your current backend tools. The front end has a web interface, the back end is all command-line. You're thinking about redoing the front end completely, in Django, and using the Django ORM interface in your existing backend scripts. For least pain, I'd use the existing database in the new Django app- see http://www.djangoproject.com/documentation/legacy_databases/ - and not worry about the ORM in your backend. When you need a new table, create it in the frontend model, run manage.py syncdb once, and there it is. If you start re-writing your backend to use an ORM, you're "fixing what isn't broken". Django can't alter tables- add columns, rename, add index, change type, etc, so won't help with many common database admin tasks. (If you really want to use the ORM- how about putting your backend into a maintenence section of your new frontend, and calling it with "wget" or the like?) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ForeignKey model vs. Foreign Key database
I was looking at the Django-created database structure for my project in a tool that shows all the foriegn-key relationships with nice little lines (aka ER diagram). It looked very sparse. Most of my relationships weren't showing up. A little digging shows me that MySQL (windows, 5.0, InnoDB tables) ignores the "REFERENCES" clause on a column. The only foreign keys it was creating were the ones listed as "pending_references" in management.py- that is, foreign key references created by altering the original table after the referred-to table was created. It was easy enough for me to add "FOREIGN KEY" clauses in management.py and I was going to submit a patch, but I hit an issue. Either I've hit a case that's not being tested, or no database checks that the REFERENCES field points to an existing table... My project has two apps, like so: app1.models: from app2.models import Zinger class Review(models.Model): critique = models.TextField zinger = models.ManyToMany(Zinger) app2.models: class Zinger(models.Model): wit = models.TextField speaker = models.CharField(maxlength=80) management.py creates the tables for the app that comes first alphabetically, so it makes Foo and Foo's many-to-many table before app2_zinger appears. And, django/core/management.py creates the SQL for Foo's many-to-many table assuming both the referred-to tables already exist. It doesn't have access to the "already created" list nor a way to add to pending references. Since MySQL is ignoring the REFERENCES, there's no problem, but when I add FOREIGN KEY, I can't "syncdb" anymore. I'm thinking I should write a django test like my foo/zinger example above (with better names, perhaps). Where would it go? Presumably somewhere under tests/modeltests? Also, if I want to make _get_many_to_many_sql_for_model add FOREIGN KEY constraints should I: a) pass in (known/seen/created)_models, and return pending_references? b) create a Model on the fly and call get_sql_create on it? Or would that be _get_sql_model_create, which also need a known_models in and pending_references out... c) ignore Foreign Key on many_to_many entirely, things will break if the constraint's enforced --~--~-~--~~~---~--~~ 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: finding verbosity in tests.py?
On Jan 31, 8:59 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 2/1/07, yary <[EMAIL PROTECTED]> wrote: > > Quick question- how do I find the verbosity in which my tests are > > running? something like "from import verbosity"? > ... > There is no scheme to pass verbosity down to the individual test cases > - mostly because test cases shouldn't be producing output. Thanks. Makes sense. MySql was giving me an error "Commands out of sync; you can't run this command now" when I ran my tests with verbosity 0 or 1, but not with verbosity 2! Was going to try and nail it down some more, but I can't reproduce it reliably, and now it seems to have vanished. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
finding verbosity in tests.py?
Quick question- how do I find the verbosity in which my tests are running? something like "from import verbosity"? --~--~-~--~~~---~--~~ 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: Post-post_syncdb signal?
On Jan 23, 6:10 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote (in different order): > One of the goals of the fixtures framework is to rename 'initial data' > to 'custom SQL' - the goal here being to move the loading of initial > data out of SQL statements into a database independent fixture format > (JSON, XML, etc), reserving the 'custom SQL' step for any table > modifying statements required by a project. A good goal and a good plan. > One option for a workaround Is to try using the ticket #2333 fixtures > patch (a version of which will be in Django v1.0) and see if that > helps. The app will run on a host where I don't have control over the Django install- though I can probably work around that :-) And I have a workaround for now, will just run my group-creation script manually. So will wait for Django 1.0. > The syncdb process does the following, in the following order: > - adds any new models > - For each model in the app (including old models): > - Invoke the post_syncdb signal > - if the model is new, install the initial data/SQL for the app > - Install the SQL indicies for the model ... > A post-post signal won't fix the problem; if you have a post-post > signal, then why not a post-post-post signal, and so on - the > underlying problem is resolving dependencies. Forcing installation > data fixtures into the last phase will resolve the dependency problem > you have described. Two things- going back to my original issue, the post_syncdb signal wasn't working because the custom permissions (in the Meta nested class) weren't yet created. I also noticed the SQL hadn't been executed, which wasn't an issue for me, but was easier to illustrate. The other thing, if I understand patch #2333, the syncdb order will be: 1. add any new models 2. For each model in the app (including old models): 3. if the model is new, install initial fixture 4. Invoke the post_syncdb signal 4.1 contrib.auth listens to post_syncdb to create custom permissions (my guess as to how it's done now, won't change?) 5. if the model is new, install the initial data/SQL for the app 6. Install the SQL indicies for the model If that's correct, then I still have a problem, because I'm hoping to reference some custom permissions. Unless step 5 is going to become python code being executed, and not a stright-up SQL file being loaded, or ... what will the syncdb order be, exactly? 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 -~--~~~~--~~--~--~---
Post-post_syncdb signal?
I'm setting up some group permissions in management.py but am running into (I think) order-of-signalling issues. When I get my post_syncdb signal, my apps models are in the database, but the custom permissions (class Meta: permissions =...) aren't created. Also by looking at the verbose output of syncdb, the signal is coming before django loads the initial data (from the app/sql directory). I presume that the custom permissions and initial data loading is also kicked off from the post_syncdb signal, and that my management.py is getting the signal first. How to fix/work around? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Splitting models.py into separate modules
Does this post still hold true- http://groups-beta.google.com/group/django-users/msg/05ed44bf585a2d09? that is, can I separate a models file into separate modules so long as I set the __all__ variable in modules/__init__.py and keep the modules in the models directory? It doesn't seem to be working that way in 0.96-pre and I'm wondering if I'm doing it wrong, or if this method's been depreciated. 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: moving django applications
You can set up your main site urls.py to read something like:
urlpatterns = patterns('',
(r'^app1/', include('app1.urls')) # Pass to app1
(r'^app2/', include('app2.urls')) # Pass to app2
)
and within app1, have a urls.py like this:
urlpatterns = patterns('',
(r'^view/(?P\d+)', 'view') # call 'view"
(r'^admin/', include('django.contrib.admin.urls')),
)
Then visiting 'http://example.com/app1/view/23' will do as you expect,
and you can rename the apps by changing only the site's urls.py and not
your apps urls.py and templates (if they use relative URLs)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Django admin confuses '' with null on foreign char primary key
While we're on the subject of null vs '' (empty string), here's a perverse case: class TestSlug(models.Model): sluggy=models.SlugField(maxlength=17, primary_key=True,blank=True,null=False, editable=True) name=models.CharField(maxlength=40) def __str__(self): return "'%s': %s" %(self.sluggy,self.name) class Admin: pass class TestSlugRef(models.Model): testslug= models.ForeignKey(TestSlug, default=HOME_SLUG, blank=True, null=False) viewed_by = models.CharField(maxlength=40) class Admin: pass Create some testslugs, give one a blank "sluggy" primary key. Create some TestSlugRefs- if you try selecting the testslug with an empty primary key, the admin says: OperationalError at /admin/test/testslugref/2 (1263, "Column was set to data type implicit default; NULL supplied for NOT NULL column ...") admin ought not be trying to use a null when the field is explicitly null=False... tried to submit a ticket, got 'Askimet rejected spam' --~--~-~--~~~---~--~~ 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: Many-to-Many with Intermediate Table
I'm not in front of the dev machine, but I created the model in 0.95, so maybe that's a dev feature. Or I may have had a typo in a model the first time through- in fact I recall that I had a space in 'class Model C', so if the 'name clash' detection requires all models to be created at once, that's how it got bypassed. So Django does check for name clashes already (under ideal circumstances). Having a 'join_model' will be helpful for a feature my client wants, I'll try making the name clash detection work for that too, and post the results. --~--~-~--~~~---~--~~ 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: Many-to-Many with Intermediate Table
Russell Keith-Magee wrote: > On 11/3/06, yary <[EMAIL PROTECTED]> wrote: > > > > The idea here is that adding a 'realation_model' option to ManyToMany > > This idea has been suggested previously, and has been rejected > previously - it has some problems when you hit queries. > > > All queries seem pretty straightforward. > > In your example, yes. However, as always, the devil is in the detail. > Consider: > > class ModelA(Model): >name = CharField(...) > > class Relation(Model): >name = CharField(...) > > class ModelB(Model): >name = CharField(...) >relation = ManyToManyField(ModelA, relation_model=Relation) > > What is the meaning of: > > ModelA.objects.filter(relation__name='foo') > > Does this query reference the name of the Relation model, or of ModelB? > > This is an artificial example, but it represents the crux of the > problem - there is no easy way to integrate queries over the > intermediate table without introducing ambiguities in queries over the > related table. I see your ambiguity, and raise you one: class ModelA(Model): name = CharField(maxlength=40) class ModelB(Model): name = CharField(maxlength=40) relation = ForeignKey(ModelA, related_name='relation') class ModelC(Model): name = CharField(maxlength=40) relation = ForeignKey(ModelA, related_name='relation') What is the meaning of: ModelA.objects.filter(relation__name='foo') ? Django's model syntax already allows ambiguities. I just tried the above, and Django doesn't complain when you create the model, it does when you try to use the filter. Which leads me to think of five possible solutions: 0. Remind people that the convention for both ForeignKey and ManyToManyFields is to use the name of the foreign model when building the field name. The contrived example is ambiguous because it defies that practice and uses the relation name instead. Problem solved by cultural norm. 1. Current solution, as "the way it is in 0.95": allow ambiguities, if the app writer contrives a painful model, they live with the pain and can't use the masked attribute. Problem solved by loud complaining late in the game. 2. Open a ticket to have Django warn about ambiguous models at syncdb time, so model creator will know to rename attributes/set up distinctive "related_name". Problem solved by gentle prodding early in game. The last two aren't serious, but they'd fix it too: 3. Always require programmer to specify which model they want when traversing a join. Problem solved by excessive verbosity. 4. Drop relations from the Django DB model altogether. Problem solved by excessive pedanticness. Summing it up: ambiguity exists now, and it hasn't stopped Django from providing very useful features. Fixing ambiguity is a related but separate issue. To fix that, I'd vote for #2 (and only warn, because there could be ambiguity in existing apps that work now, because they never tickle the overloaded filters). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Askimet is for blogs (was Re: django/db/models/base.py:383: Local variable (rel) not used)
> ...I've submitted this to trac, was rejected by akismet as spam. It's time django's trac used a local 'dspam' instance instead of relying on askimet's, because most trouble tickets don't resemble blog comments. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Many-to-Many with Intermediate Table
My previous brainstorm relied on magic- Models that look like fields? auto-synthesized composite classes!? Django went through a magic removal, adding magic won't fly. An antidote to magic is explicitness. Let's try the previous example from a different angle, spelling everything out. class Reporter(models.Model): first_name = models.CharField(maxlength=30) last_name = models.CharField(maxlength=30) class Article(models.Model): headline = models.CharField(maxlength=100) pub_date = models.DateField() # Here's the new option 'reation_model' - am open to tweaking the name! writers = models.ManyToManyField(Reporter, relation_model='WritingRole') class WritingRole(models.Model): responsibility = models.CharField(maxlength=30) description = models.CharField(maxlength=30) pay_scale = models.ForeignKey(PayScale) The idea here is that adding a 'realation_model' option to ManyToMany field tells it to use the named model, instead of a hidden one. Syncdb won't create a table when it sees that. Django should check if 'WritingRole' has the needed foreign keys, if not, it'll add article = ForeignKey(Article) reporter = ForeignKey(Reporter) # lowercase the model name, underscore CamelCase- precedant for that All queries seem pretty straightforward. # how often do people named Smith work for free? WritingRole.objects.filter(reporter__last_name='Smith',actual_pay=0).count() # Who were the muses? WritingRole.objects.filter(responsibility=MUSE).reporter.all() How about getting to the WritingRole model? # Another way of finding overly generous Smiths Reporter.objects.filter(last_name='Smith',writing_role__actual_pay=0).count() # writing_role_set is a reverse relationship from both sides # find unpaid writing roles, assuming only one Smith Reporter.objects.get(last_name='Smith').writing_role_set.filter(actual_pay=0) # find muses for an article Article.objects.get(pk=1).writing_role_set.filter( responsibility=MUSE).reporter.all() How did writing_role become a filter on the Article & Reporter managers? How did the models get a writing_role_set? That's easy- it came from the WritingRole model, same as it does now! Changing the related names should be as easy as: class WritingRole(models.Model): responsibility = models.CharField(maxlength=30) description = models.CharField(maxlength=30) pay_scale = models.ForeignKey(PayScale) # explicitly name the required ForeignKeys for this M2M model published_item = ForeignKey(Article, related_name='roles_and_payments') helper = ForeignKey(Reporter, related_name='chores_and_income') phew. Now, back to the post that handled it all- how to handle in the admin? When the admin sees a M2M field with a 'relation_model' option, it should treat it as a ForeignKey to the relation model... so if the example Article model has a 'class Admin', it will allow edits to WritingRoles. Which means 'edit_inline' should also be an available option for ManyToMany if relation_model is specified. I'm happy with this proposal. Low magic, and it mostly uses code already in Django. In fact I think I could write up patches for it, despite being a realitve newbie to Django. Discussion? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Many-to-Many with Intermediate Table - How to?
Wow, I hate being verbose and wrong at the same time in public. Take my previous post with a grain of salt while I rethink it! sorry... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Many-to-Many with Intermediate Table - How to?
Russell Keith-Magee wrote:
...
> That said, 'm2m with intermediate' is a relatively common use case, so
> if you have any neat ideas on how to represent such a structure, feel
> free to suggest them. The idea has been discussed before, but no
> obvious solution has emerged (the real sticking point is querying the
> intermediate table - check the archives for previous discussions).
Here's some brainstorming. This post is long, and it's all daydreaming.
I suspect someone else may have already come up with the same answer
and it doesn't work for some reason... Checked the archives, found some
relevant discussions, but not sure I found the right ones :-/
The problem is, how to add some attributes to a ManyToMany relation-
how to define them and use them. Django currently hides the
intermediate table, and that's good. It can stay hidden for the usual
use case, where all you want is a many-to-many relationship. I think,
when someone wants to add "fields" to the relationship, then it should
become visible, and also synthesize models with both relationship
attributes and table behavior.
How would it look?
Starting with defining half, the inner Meta class seems like a good
place to go:
class Reporter(models.Model):
first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=30)
class WritingRole(models.Model):
responsibility = models.CharField(maxlength=30)
description = models.CharField(maxlength=30)
pay_scale = models.ForeignKey(PayScale)
class Article(models.Model):
headline = models.CharField(maxlength=100)
pub_date = models.DateField()
writers = models.ManyToManyField(Reporter)
# Here's a stab at 'm2m with intermediate' defining syntax
class Meta:
writers.actual_pay=models.SmallIntegerField() # We don't pay
much!
writers.writing_role=models.ForeignKey(WritingRole)
That's it. Looks pretty clean, is easy to understand.
Maybe the "writers.' don't even go in the Meta subclass, maybe
they stay in the main class.
Recursion requires a little thought.
# 'self' should always mean 'this model',Article in this case
writers.similar_articles=models.ForiegnKey('self')
# so spell out when you really want to self-relate
writers.collusion_group=models.ForeignKey('Article.writers')
# And someone will find a need for ManyToMany recursion!
How to use?
The old API doesn't change, things work as always
art = Article.objects.get(pk=3)
writers = art.writers.all() # as usual, gives all reporters
writer1 = reps[1] # get a single reporter from the list
print writer1.last_name # "Smith"
written_things = writer1.article_set.all() # find all articles for
the reporter
print written_things[0].headline # "Django Gets Useful Model
Enhancements"
Maybe you're wondering why I didn't call the variables "reporter" and
"article". I'm thinking that when you define "writers"- when you define
a relationship with attributes- you're saying that the model on the
other side has something extra, when viewed from this side. So, you get
a subclass of the foreign model.* It does all the things that the
related class does, plus lets you retreive the attributes for that
particular relation:
writer1.actual_pay # 0 if working for free!
writer1.writing_role.responsibility # "Muse"...
# describe the role writer1 had when writing this article
written_things[0].writing_role.description
Given a plain old Reporter object "reporter1":
reporter1.writers_set.all() # gets all Article-plus objects for
writer
reporter1.writers_set.get(headline='Foo') # may have the syntax a bit
off here- find Article-plus object with headline 'Foo'
reporter1.writers_set.filter(writingrole__responsibility='Author') #
find Article-pluses for which reporter1 was the author.
* I realize this abstraction my be contentious- if you ask for a
Reporter you should get a Reporter and not some subclass Django creates
for you. That's my reaction too. It does seem cleaner to make a
'Writers' object of its own that behaves like a model with two foreign
key fields, and the extra attributes. Indeed Django should, so one can
make requests like:
Writers.objects.filter(reporter__last_name='Smith',actual_pay=0).count()
# how often do people named Smith work for free?
But then how would that abstraction work for other common cases?
reps = art.writers.all() # really gives Reporters this time
rep1 = reps[1] # get a single reporter from the list
# We've lost the information we got traversing the relation!
rep1.actual_pay # gives an attribute error
art.writers.actual_pay # what writer are we talking about?
art.writers[1].actual pay # huh? Even if that syntax works to select
a single writer, 'art.writers' returns Reporters, which don't have
"actual_pay"
Writers.objects.get(article=art,reporter=rep1).actual_pay # This
works. I think it hits the database again.
So, you can get something working with an auto-created class named
after the M2M relation (with an override to l
Re: Field with null=True, blank unspecified, should allow null
yary wrote: > Do you have an example of any project in the wild, using the django > admin, with a field "null=True, blank=False, editable=True"? I'm > curious to know the use of such a beast in an actual implementation. to clarify,I do think it is useful to have "null=True, blank=False, editable=True" (ie "# of pregnancies in a population, so you don't have men counting as 0" - I just haven't seen that combination actually allow me to use it as I expect. When I try, it tells me the field can't be blank. I don't want the admin to make it blank, I want it to make the field null. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Field with null=True, blank unspecified, should allow null
James Bennett wrote: > On 10/25/06, yary <[EMAIL PROTECTED]> wrote: > > Seems that if someone says a field can be null, that implies the admin > > interface should let it be null. > > I really, really, really don't like having a system assume that one > thing I've done "implies" another thing it should do. I also don't > like breaking the consistency of "blank defaults to False any time > it's not specified". Do you have an example of any project in the wild, using the django admin, with a field "null=True, blank=False, editable=True"? I'm curious to know the use of such a beast in an actual implementation. null=True, blank=False breaks the admin UI, as it is in Django 0.95. It doesn't let the user distinguish between a blank entry and a null entry. That combination does make sense if you have a char field that you don't want blank, but would allow to be null. I changed the title of this thread to reflect that. My updated request: If a field has "null=True, blank=False, editable=True", the admin should have a way to nullify the field (and it should work weather it is numeric, character,foreign-key...) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Field with null=True, blank unspecified, should allow blank
A field specified like {{{foo=ForeignKey(Bar,null=True)}}} does not
allow blanks in the admin interface.
Specifying {{{foo=ForeignKey(Bar,null=True,blank=True)}}} allows
blanks.
Seems that if someone says a field can be null, that implies the admin
interface should let it be null.
If for some reason a coder wants a nullable field not entered blank,
they can still specify the nearly oxymoronic {{{null=True,
blank=False}}}
... I tried submitting the above as a 'trivial' enhancement request to
0.95 via code.djangoproject.com/newticket, and it got rejected as spam
three times (with minor variations), so I'm posting here.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
syncdb complaining table already exists
Hi, new to Django- I have my data model all created. I can run syncdb once, and it creates my database schema: C:\webapp\Site>python manage.py syncdb Creating table auth_message Creating table auth_group Creating table auth_user Creating table auth_permission Creating many-to-many tables for Group model Creating many-to-many tables for User model Creating table django_content_type Creating table django_session Creating table Q_category ... etc ... If I run it a second time, it fails with this error: File "c:\Python24\lib\site-packages\MySQLdb\connections.py", line 35, in defau lterrorhandler raise errorclass, errorvalue _mysql_exceptions.OperationalError: (1050, "Table 'q_category' already exists" ) Is it bad for a Django app to start with a capital letter? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
