Re: Ticket #7539 (ON DELETE support) in Django 1.2?
Hey guys, not a flame only a consideration: the best python orm/sql toolkit (sqlalchemy) already support this and many many other features/ database engines, why not move the efforts in sa integration? Using sa in django is simple but actually you cannot use admin interface On 18 Ago, 17:09, hcarvalhoalves wrote: > On Aug 17, 1:11 am, Martin Maney wrote: > > > > > On Sat, Aug 15, 2009 at 10:45:44AM -0700, hcarvalhoalves wrote: > > > ForeignKey(..., propagate_on_delete=True) > > > CASCADE > > > > ForeignKey(..., propagate_on_delete=False, null=False) > > > RESTRICT > > > > ForeignKey(..., propagate_on_delete=False, null=True) > > > SET NULL > > > > ForeignKey(..., propagate_on_delete=False, default=XXX) > > > SET DEFAULT > > > > ForeignKey(..., propagate_on_delete=False) > > > Raises Exception, need to define either "null" or "default" > > > +0.9 > > > I found the "association" style both unfamiliar and, frankly, a bit > > precious, but this is brilliant. I especially like the way it gives an > > explicit name to the most important aspect of it: whether FK > > dependencies cause an entity's deletion to propagate recursively or > > not. > > > Well, that part is brilliant. I think you're simply wrong about that > > error case: without overriding the defaults, null=False and > > default=None, you have the second case, and should get RESTRICT > > behaviour. > > My fear was making it too subtle to know what will happen without null > or default. But you're right; just assuming the defaults is correct. > > I hope this idea helps you avoiding SQL-specific terms on the patch, > I'm looking forward to see it accepted ;) --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
Sorry my intention was not a flame, I commented only beacause recently I switched a my big project from django orm to sqlalchemy for the following reasons: 1) on delete behaviuor control 2) with sqlalchemy eagerload is ever possible, if you need, get a whole graph of object with only one query, django has some limitations with many to many relation and select_related 3) sa has support for multiple database, django maybe will support multi db in 1.2 (soc project) 4) sa has support for connection pools, with django you have to use external tool (for examples pgpool for postgres) 5) with sa if you have several threads you can use the scoped_session (a new session for every thread) or decide to share the same session (at your risk, if you know what you are doing) between several threads, django open ever a new session for every thread and is not customizable 6) with sa you have out of box fine control over commit and rollback with django you have to use commit_manually to have the same behaviour (sa way is more cleaner in my opinion) 7) sa support more database engine (for example mssql) that said django orm is much simple to learn than sa, I hope django orm will become soon better than sa, drakkan On 19 Ago, 02:16, Russell Keith-Magee wrote: > On Wed, Aug 19, 2009 at 1:43 AM, drakkan wrote: > > > Hey guys, > > > not a flame only a consideration: the best python orm/sql toolkit > > (sqlalchemy) already support this and many many other features/ > > database engines, why not move the efforts in sa integration? Using sa > > in django is simple but actually you cannot use admin interface > > On the off chance that this was a well intentioned comment, and not > just at troll, I will point out that: > > * "Best Python ORM/SQL toolkit" is a _huge_ value judgement. > > * SQLAlchemy has explicitly stated that they aren't going to attempt > to solve one of the problems that Django is explicitly trying to > target - support for non-relational data stores. We aren't going to > adopt a toolkit that has said they aren't going to address a problem > we want to solve. > > That said, James is correct that this isn't a topic that requires debate. > > Yours, > Russ Magee %-) --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #2131 SendFile Support
django-sendfile works fine for me too +1 to include in django
Nicola
On 9 Gen, 09:22, Thomas Guettler wrote:
> Hi,
>
> Ticket #2131 (SendFile support) is open since 6
> years:https://code.djangoproject.com/ticket/2131
>
> The implementation is stable:https://github.com/johnsensible/django-sendfile
>
> I can live with current situation (sendfile is an external application). But,
> maybe someone wants to close this
> as "wontfix" or get these few lines into django.
>
> {{{
> Django Sendfile
>
> This is a wrapper around web-server specific methods for sending files to web
> clients. This is useful when Django needs
> to check permissions associated files, but does not want to serve the actual
> bytes of the file itself. i.e. as serving
> large files is not what Django is made for.
>
> }}}
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
django 1.8 i18n behaviour change
Hi, I updated a project from 1.7 to 1.8 (tested both 1.8.0 and 1.8.1), in my templates and python code I have string in my native language (italian), so my po files look likes this: 1) locale en msgid "original string in italian" msgstr "english translated string" 2) locale it msgid "original string in italian" msgstr "" now in settings I have: LANGUAGE_CODE = 'en' my browser is in italian so request.LANGUAGE_CODE is "it" now in django 1.7 the fallback translation is taken from the it po file, in django 1.8+ en translation is used (probably since msgstr is empty and default LANGUAGE_CODE is "en") do you consider this a bug? thanks -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4ccdde54-84a5-4b5a-a54d-9fba3bf2dc63%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: making queryset.delete issue only a single SQL query
On 17 Set, 15:38, Tobias McNulty wrote: > On Fri, Sep 17, 2010 at 8:27 AM, SmileyChris wrote: > > > On Sep 11, 1:12 pm, Tobias McNulty wrote: > > > I may be missing something, but queryset.delete() seems oddly implemented > > in > > > Django. It does a select to get all the IDs to be deleted, and then > > deletes > > > them, in blocks of 100 I believe, by ID. > > > It's because .delete() is emulating the behavior of the SQL constraint > > ON DELETE CASCADE > > > A list of objects to be deleted is recursively populated, then this > > complete list of objects is iteratively deleted (also calling the > > pre_delete and post_delete signals in their respective places). > > Hm, I see that now, and I suppose there's no sense in changing that > behavior. > > To my credit, the docs are a little misleading, specifically the line > reading "Keep in mind that this will, whenever possible, be executed purely > in SQL, and so the delete() methods of individual object instances will not > necessarily be called during the process." [1] Additionally, is ambiguous > whether the part about "ON DELETE CASCADE" applies just to single objection > deletion or to queryset deletion as well. Admittedly what it says is not > wrong, but it does /suggest/ that delete() on a queryset doesn't do anything > per-object, which is not true at all. > > Perhaps I'll work on clarifying the docs and adding a warning that Django's > delete() on a queryset will chunk the actual deletions--in addition to > calling signals and deleting related objects one by one--so raw SQL should > be used instead if one needs to delete a lot of rows and efficiency is a > concern? Does that seem reasonable? in my opinion django should emulate "ON DELETE CASCADE" only on database backends that doesn't support it, if you are using a database such as postgres delete() on a queryset should issue a single sql query and should be the database to care about the cascade/set null etc.. behaviour http://code.djangoproject.com/ticket/7539 I think this way django could archive the best performance, if one need to delete a lot of row and there are relations to other tables a single raw SQL query is not enough, you need to modify the database schema too to ensure the correct cascade behaviuor or you need to issue an sql query for every related table Nicola > > Tobias > > [1]http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects > -- > Tobias McNulty, Managing Partner > Caktus Consulting Group, LLChttp://www.caktusgroup.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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: prefetch_related - new feature suggestion
This look great! I think this approach is better than the one's used
by other orms that force a single, heavy, query to retrieve the whole
many to many object graphs, would be nice to see it in 1.4
thanks
Nicola
On 1 Ott, 04:42, Luke Plant wrote:
> On 29/09/11 21:43, Alex Gaynor wrote:
>
> > When I did this externally a number of years ago, I basically subclassed
> > ManyToManyField, overrode a bunch of code (quite a bit of copy paste as
> > I recall), and it's related manager and made it return a custom
> > queryset, which used a cache off of the object, which was populated by
> > another custom queryset which overrode iterator() in order to do the
> > bulk loading.
>
> I've had another go, and I think it should be a lot more convincing now.
>
> https://code.djangoproject.com/attachment/ticket/16937/prefetch_3.diff
>
> It supports arbitrary depth, so you can do things like:
>
> User.objects.prefetch_related('groups__permissions')
>
> and it will also traverse singly-related objects (foreign key and
> one-to-one) in the chain.
>
> The implementation is significantly nicer, as it splits up
> responsibilities between QuerySet and the related managers the way it
> ought to be. One piece of evidence that the separation is good is that I
> implemented support for GenericRelations as a final step, and did so
> without touching the core 'prefetch_related' code at all - I simply
> added some methods to the manager produced by GenericRelation. This also
> means that the implementation could provide support for things like
> GenericRelation but in 3rd party apps.
>
> The implementation can also cope with the presence of a
> prefetch_related() fields already on any prefetched QuerySets (which can
> happen if a default manager has used prefetch_related), and will simply
> fold in the work to optimize the queries.
>
> With these things in place, it was literally a couple of lines to take
> one of my admin pages from 176 queries to 8.
>
> I think the combination of features here makes it a *very* compelling
> alternative to doing it outside core. Have I convinced you Alex? :-)
>
> I would like at some point to tackle the ability to prefetch objects
> with custom filters, as discussed on the ticket, rather than just the
> 'all()' case. However, that can wait, and I'd like some people to have a
> bash on this and find the bugs. It would be really nice if this could
> get in before the 1.4 alpha, because it has turned out to be a pretty
> neat feature I think.
>
> Regards,
>
> Luke
>
> --
> "It is a truth universally acknowledged, that a single man in
> possession of a good fortune, must be in want of a wife." (Jane
> Austen)
>
> Luke Plant ||http://lukeplant.me.uk/
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
migrate id field from integer to biginter (probable bug)
Hi,
I have two models like these:
class Allarme(models.Model):
class Registrazione(models.Model):
allarme = models.ForeignKey(Allarme, blank=True, null=True,
on_delete=models.DO_NOTHING, db_constraint=False)
now I want to change id field for these models from int to bigint so I
added to both
id = models.BigAutoField(primary_key=True)
and I did the migration,
python manage.py sqlmigrate
show something like this:
BEGIN;
--
-- Alter field id on allarme
--
ALTER TABLE "multimedia_allarmi" ALTER COLUMN "id" TYPE bigint USING
"id"::bigint;
DROP SEQUENCE IF EXISTS "multimedia_allarmi_id_seq" CASCADE;
CREATE SEQUENCE "multimedia_allarmi_id_seq";
ALTER TABLE "multimedia_allarmi" ALTER COLUMN "id" SET DEFAULT
nextval('"multimedia_allarmi_id_seq"');
SELECT setval('"multimedia_allarmi_id_seq"', MAX("id")) FROM
"multimedia_allarmi";
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "allarme_id" TYPE
bigint USING "allarme_id"::bigint;
*ALTER TABLE "multimedia_registrazioni" ADD CONSTRAINT
"multimedia_registrazioni_allarme_id_4919213e_fk" FOREIGN KEY
("allarme_id") REFERENCES "multimedia_allarmi" ("id") DEFERRABLE INITIALLY
DEFERRED;*
--
-- Alter field id on registrazione
--
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "id" TYPE bigint USING
"id"::bigint;
DROP SEQUENCE IF EXISTS "multimedia_registrazioni_id_seq" CASCADE;
CREATE SEQUENCE "multimedia_registrazioni_id_seq";
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "id" SET DEFAULT
nextval('"multimedia_registrazioni_id_seq"');
SELECT setval('"multimedia_registrazioni_id_seq"', MAX("id")) FROM
"multimedia_registrazioni";
COMMIT;
so as you can see a foreign key is added for a model field with
db_constraint=False,
can you please confirm that this is a bug? I'm using django 1.11.1
thanks!
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/18bafe5a-6cc0-412d-8e51-672b15f08325%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
