Re: Django ORM
> Sorry to have to say the last part is pure nonsense. Preserving data > integrity is of course the only sane default behaviour. How could NOT > preserving data integrity be "dangerous" ??? looonng query ? And ? So > what ? You are supposed to know your data model, don't you ? Bruno, I'm assuming your problem here is that you haven't read the thread. Cascading deletes can be enabled in MySQL and are, apparently, enabled by default on PostgreSQL. If this is the case, it would be dangerous to allow potentially thousands of select statements to be executed, in a loop, due to a seemingly innocuous web operation... all without any need whatsoever. Web development 101 would teach you that this can be dangerous and easily lock your site. It was knowing my data model that had me investigate this. I would recommend to you two things, a) log your query activity to learn what's going on under the covers and b) try something to help relieve your anger. > As for the "many developpers were bit by this", anyone in this > situation is obviously not qualified to work as a programmer. Not in > my team at least. I'm sure your team is top notch and they would never tolerate query slop. -- 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.
Re: Disabling Messaging
I'm using 1.1.1 now. Any idea when there will be a 1.1.2 release? Is
the current branch considered stable?
Thanks Russ.
On Mar 23, 8:12 pm, Russell Keith-Magee
wrote:
> On Wed, Mar 24, 2010 at 5:01 AM, jrs wrote:
> > Thanks Preston.
>
> > I'm not using django'smessaging... at all. My problem is that for
> > every ajax request, the query-
>
> > {'time': '0.000', 'sql': u'SELECT `auth_message`.`id`,
> > `auth_message`.`user_id`, `auth_message`.`message` FROM `auth_message`
> > WHERE `auth_message`.`user_id` = 1 '}
>
> > is being run. I can't figure out how I can stop this unnecessary
> > database activity.
>
> It depends on what version of Django you are using?
>
> If you're using 1.1.1 or earlier, there's not much you can do. The
> problem you describe is caused by the auth context processor, which is
> required by tools such as admin.
>
> If you're using 1.1.X (the latest code on the 1.1.X branch), this
> problem has been fixed; messages has been made lazy, so you won't
> incur the database hit unless you specifically request the messages
> attribute.
>
> If you're using trunk (which will soon become 1.2), the problem has
> completely changed -messagingis now a configurable activity, so you
> can choose to completely disable messages (although admin will no
> longer work), or you can opt to use a non-database store for messages.
> You could even write a 'dummy' store for messages that implements
> themessaginginterface, but does nothing with those messages.
>
> 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.
Re: Django ORM
Another great example... If PostgreSQL has referential integrity on by default, is django still hammering the db with unnecessary queries? I've already seen that it does when MySQL has referential integrity on... It seems people are confirming the django problem... I'm not trying to argue doing away with referential integrity, I'm arguing that django should not force the developer to accept it's unnecessary pummeling of the db when integrity is being maintained in some other way, such as postgreSQL built in functionality... I thank you guys for making my point more clearly than I've been able to! On Mar 23, 5:56 pm, James Bennett wrote: > On Tue, Mar 23, 2010 at 3:57 PM, jrs wrote: > > It is precisely due to this that I'm surprised the ORM has > > cascading deletes on by default. Seems to me that cascades should > > only happen when the app developer specifies, not the other way > > around... it's dangerous and I'm certain that many developers were bit > > by this. > > Then I guess you and all those other developers should start lobbying > database vendors to stop building referential integrity by default > into their products, since vendors like PostgreSQL have exposed far > more people to this "danger" than Django has... > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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.
Re: Django ORM
Clifford, Ask the previous engineering staff of Twitter if it's dangerous. On Mar 23, 5:26 pm, CLIFFORD ILKAY wrote: > On 03/23/2010 04:57 PM, jrs wrote: > > > Russ and Javier, > > > Just to be clear... the reason for my initial note was due to my > > already having a work queue which performs cleanup and maintains > > data integrity. It is precisely due to this that I'm surprised the > > ORM has cascading deletes on by default. > > Your "surprise" doesn't make it wrong. > > > Seems to me that cascades > > should only happen when the app developer specifies, not the other > > way around... > > No. The default behaviour should always be to protect data integrity. I > take it you're a MySQL user. > > > it's dangerous and I'm certain that many developers > > were bit by this. > > "Dangerous"? It's dangerous NOT to enforce referential integrity by > default and I hope that Russ et al don't spend even a second thinking > about how to implement a means of turning this off. If you want to play > database engine and take responsibility for maintaining referential > integrity, go ahead and use raw SQL, though you might have to work at it > if you have a real database. > -- > Regards, > > Clifford Ilkay > Dinamis > 1419-3266 Yonge St. > Toronto, ON > Canada M4N 3P6 > > <http://dinamis.com> > +1 416-410-3326 -- 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.
Re: Disabling Messaging
Thanks Preston.
I'm not using django's messaging... at all. My problem is that for
every ajax request, the query-
{'time': '0.000', 'sql': u'SELECT `auth_message`.`id`,
`auth_message`.`user_id`, `auth_message`.`message` FROM `auth_message`
WHERE `auth_message`.`user_id` = 1 '}
is being run. I can't figure out how I can stop this unnecessary
database activity.
On Mar 23, 2:20 pm, Preston Holmes wrote:
> On Mar 23, 8:20 am, jrs wrote:
>
> > Is there a flag somewhere which will allow me to disable django
> > messaging?
>
> > Thanks
>
> You give too few details. The messaging system is something that is
> opt in, you have to create messages, and then display them in your
> template. Are you trying to alter an existing system? Removing
> references to messages in your templates is the fastest way to disable
> them without incurring other breakage in the apps.
>
> -Preston
--
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.
Re: Django ORM
Russ and Javier, Just to be clear... the reason for my initial note was due to my already having a work queue which performs cleanup and maintains data integrity. It is precisely due to this that I'm surprised the ORM has cascading deletes on by default. Seems to me that cascades should only happen when the app developer specifies, not the other way around... it's dangerous and I'm certain that many developers were bit by 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.
Disabling Messaging
Is there a flag somewhere which will allow me to disable django messaging? 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-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.
Re: Django ORM
Thanks Russ On Mar 23, 10:33 am, Russell Keith-Magee wrote: > On Tue, Mar 23, 2010 at 10:21 PM, jrs wrote: > > > On Mar 23, 10:05 am, "ge...@aquarianhouse.com" > > wrote: > >> Filter would be better :) > > >> Container.objects.filter( > >> pk=container_id > >> ).delete() > Reasons I see that makes get() a better option- 1) There will always be one record returned as it's a join on a primary key 2) For reasons unknown to me, the overridden model delete method is not fired for a filter, instead the 581 queries are executed. The recommendation to avoid web requests for long-chain deletes, most of the time, makes no sense. There are frequently valid cases of long- chain deletes being basic to web requests. -- 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.
Re: Django ORM
On Mar 23, 10:05 am, "ge...@aquarianhouse.com" wrote: > Filter would be better :) > > Container.objects.filter( > pk=container_id > ).delete() Why is filter better here, since it's a one record delete? Also, am I correct is believing that this creates a painfully easy way to bring down the house with a trivial delete? 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-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.
Django ORM
I have a statement--- Container.objects.get( pk=container_id ).delete() This seemingly trivial operation hammers the db with 581 queries!! The reason being that the django orm has decided that it will enforce referential integrity as a default behavior. As you could imagine, this seemingly trivial operation could bring down a site in no time. I guess the answer is to override the models delete() method. If this is the case, why is CASCADE not used as an optional attribute by django? Why is it the default? Aren't we looking at an obvious way for a developer to bring down the house with a seemingly simple 1 record delete? 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-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.
Re: Self Join
Thanks... I'm perfectly comfortable with using foreign keys (and reverse) with the django orm. For basic joins this is fine. For more advanced queries involving complex aggregations (ie-reporting), the orm seems to be pretty useless... looking at the generated sql shows this. It's It's quite easy to produce some nasty queries in loops. I'm guessing the if the simply query above can't be accomplished that I'm better off trying straight sql or sql alchemy. On Mar 15, 11:21 am, Daniel Roseman wrote: > On Mar 15, 1:40 pm, jrs wrote: > > > I see nothing on this page that is in the slightest bit related to my > > question... Does anyone know if there is a way in the django orm to > > accomplish my query above? > > > Thanks. > > As I explained, there's nothing different in a self-join than with any > other sort of join. And so as of course you'll know, because you've > read the documentation, you can always access a related object via the > ForeignKey field: > accountinstance = Account.objects.get(pk=whatever) > accountinstance.parent_account > > If (for performance reasons) you need to get both with a single query, > use select_related(): > accountinstance = Account.objects.select_related().get(pk=whatever) > -- > DR. -- 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.
Re: Self Join
I see nothing on this page that is in the slightest bit related to my
question... Does anyone know if there is a way in the django orm to
accomplish my query above?
Thanks.
On Mar 13, 4:17 am, Daniel Roseman wrote:
> On Mar 12, 10:54 pm, jrs wrote:
>
>
>
> > I'm trying, without a great deal of success, to perform a simpleself
> >joinusing the django orm. I'm pretty sure the F() function is not
> > the answer. I believe this only allows you to compare two field
> > within the same model instance, not to compare fields within 2
> > instances of the same model. I want to do this -
>
> > Model-
>
> > class Account(models.Model):
> > name = models.CharField(max_length=255)
> > parent_account = models.ForeignKey('self', default=None,
> > blank=True)
>
> > SQL-
>
> > SELECT account.*, parent.*
> > FROM account
> > LEFTJOINaccount parent ON
> > account.id = parent.parent_account
>
> > This seems pretty basic, but I can't find any way to do it.
>
> > Thanks
>
> Accessing aselfjoinis no different from accessing any other related
> objects. Read this:http://docs.djangoproject.com/en/1.1/ref/models/relations/
>
> It helps not to think in terms of SQL, but in terms of objects, when
> using the ORM.
> --
> DR.
--
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.
Self Join
I'm trying, without a great deal of success, to perform a simple self
join using the django orm. I'm pretty sure the F() function is not
the answer. I believe this only allows you to compare two field
within the same model instance, not to compare fields within 2
instances of the same model. I want to do this -
Model-
class Account(models.Model):
name = models.CharField(max_length=255)
parent_account = models.ForeignKey('self', default=None,
blank=True)
SQL-
SELECT account.*, parent.*
FROM account
LEFT JOIN account parent ON
account.id = parent.parent_account
This seems pretty basic, but I can't find any way to do it.
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-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.
fieldsets in newforms
I am trying to use fieldsets and newforms, looking at the newforms-
admin branch it appears as if support will be included in the admin,
but I am not sure of how to integrate this into my custom forms.
Is the following possible / are there plans for doing something like
the following?
{{ form.as_table }}
resulting html along the lines of:
or even
{{ form.fieldset1.as_table }}
{{ form.fieldset2.as_table }}
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: not receiving error email
Have you tried the SERVER_EMAIL setting in settings.py? For me that did the trick SERVER_EMAIL = '[EMAIL PROTECTED]' Without that it was sending the exception emails from [EMAIL PROTECTED] which my shared provider (webfaction which I highly recommend) did not like. jrs On Jan 31, 6:37 pm, James Tauber <[EMAIL PROTECTED]> wrote: > I just got an unhandled exception error on my production site but > didn't receive an email. > > I have ADMINS set and django in general has no problem emailing > (account activation works fine). > > Is there something else I need to do to get error emails? > > Any other suggestions as to what to look for that would cause the > error email to not be sent? > > James --~--~-~--~~~---~--~~ 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: Table prefix problems
I actually looked into this yesterday and came up with the following modification to db/models/options.py around line 37 def __setattr__(self, name, value): if (settings.DB_PREFIX != '' and name == 'db_table' and value != ''): self.__dict__[name] = DB_PREFIX + "_" + value else: self.__dict__[name] = value Where a new option is added to settings. This is pretty crude but in my initial test it appeared to work. This solution would not allow for sharing users between the sites Or is this 'incredibly hackish' Disclaimer I am not a python programmer, but I did stay at a Holiday Inn Express last night. So this may be way off base. --~--~-~--~~~---~--~~ 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: simple search pagination
submit.x and submit.y are the coordinates of where the user clicked the submit image. --~--~-~--~~~---~--~~ 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: DateTimeField
I believe you need 2 fields on your form:
{{form.EndTime.time}} and {{form.EndTime.date}}
--~--~-~--~~~---~--~~
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: hide drop-down items with generic views?
I have used custom manipulators to do this http://www.djangoproject.com/documentation/forms/ class PollAddManipulator(Poll.AddManipulator): def __init__(self, season): super(Poll.AddManipulator, self).__init__() newfields = [] for field in self.fields: if field.field_name == 'category': field = forms.SelectField(field_name='category', choices=Category.objects.filter(active==true) newfields.append(field) self.fields = newfields --~--~-~--~~~---~--~~ 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: TEMPLATE_DIRS relative to project?
I have solved this by using a settings_env.py file. At the top of my settings.py file I have from settings_env import * then inside settings_env.py I define MY_BASE_PATH = /absolute/path/to/project/ so that inside settings.py the template becomes TEMPLATE_DIRS = ( MY_BASE_PATH + 'templates' ) MEDIA_ROOT can also use MY_BASE_PATH. Then I just exclude settings_env.py from the rsync command that posts the site. I also have my database, base_url, cache and any other environment specific configuration there. Works like a charm. john --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
