Complains about FileField not deleting files in 1.3.
I am referring to this: http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files Instead of preventing the data loss from happening a very usefull feature has been removed. Why not simply letting the developer decide when to enable or disable it with a constructor boolean parameter? My company sells multimedia web applications normally handling over 1 files over various models. I am sorry to say that but to me the idea of running a cron job to remove orphaned files does not seam to be practical. Shall I make a query for each file? This will make it very hard to switch projects from 1.2 to 1.3. The roll back data loss problem could have been solved by copying the file into a temporary file and by restoring it if necessary. Having to file fields pointing to the same file does not sound correct. However this is probably the only case in which it would make sense to disable the auto deletion. Am I the only one who would like to see the previous behaviour restored? Can we at least re-enable this feature from the file-field constructor? -- 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: Complains about FileField not deleting files in 1.3.
On 03/27/2011 06:42 AM, -RAX- wrote: > I am referring to this: > http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files > Instead of preventing the data loss from happening a very usefull > feature has been removed. Well, it does also prevent the data loss from happening ;) This data loss is not a hypothetical problem; we had bug reports from users affected by it. > Why not simply letting the developer decide when to enable or disable > it with a constructor boolean parameter? > > My company sells multimedia web applications normally handling over > 1 files over various models. > I am sorry to say that but to me the idea of running a cron job to > remove orphaned files does not seam to be practical. Shall I make a > query for each file? I don't see why that would be necessary. One query for each model containing one or more FileFields is enough to build a list of the files that ought to exist, and any file not in that list can presumably be removed. > The roll back data loss problem could have been solved by copying the > file into a temporary file and by restoring it if necessary. Emulating the transactional behavior of a relational database is not that trivial. We considered this approach carefully and decided that if we tried to go down that road, we'd be continually finding and fixing edge-case bugs in it, and any bug in it would be likely to be a data-loss bug. Deleting files when we can't be sure it's the right thing to do is a very dangerous business to be in. > Am I the only one who would like to see the previous behaviour > restored? Can we at least re-enable this feature from the file-field > constructor? If you want the previous behavior, it's not at all difficult to restore it with a post-save signal handler. You can make your own trivial subclass of FileField that attaches this post-save handler in the contribute_to_class method: that's precisely what FileField used to do. Carl -- 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: Complains about FileField not deleting files in 1.3.
On Sun, Mar 27, 2011 at 5:42 AM, -RAX- wrote: > I am referring to this: > http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files > Instead of preventing the data loss from happening a very usefull > feature has been removed. I'm sorry this caused an problem for you. Hopefully it's not *too* big a deal: a FileField subclass along the lines Carl suggested should be able to provide the same behavior has you've seen before at minimal effort. I'd do something like: https://gist.github.com/889692. But just for the record, we're pretty much always going to make calls like this. Data loss is one of the few places I'm happy to break backwards compatibility. When it comes down to unexpected data retention versus unexpected data loss we're always going to try to err on the site of retention. Too much data's easy to deal with: delete some stuff. But lost data means a trip to the backups if you're lucky, and a really bad day (or week, or month, ...) if you're not. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Add current_app to request and pass it to template loaders.
Now that 1.3 is out, does any core dev have an opinion, feedback or suggestions on this? I've solved my immediate need with two template loaders (subclasses of the app_directories loader) that use thread locals. One prefixes the requested template name with the app name and the other prefixes it with the namespace. But I'd still like to see Django improved so that users can create template loaders which have access to the current app. It would also be nice for process_view middleware to have access to the other attributes of the ResolverMatch object (app name, namespace, etc) to avoid having to resolve URLs twice. Cheers. Tai. -- 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: Trac components cleanup
Hi all, Now that 1.3 has been released (yay!), I'm reviving this thread to see if we can make Trac a little more efficient on our way to 1.4. I'll try to summarise what's been suggested so far in regard to improving and clarifying the "Component" field: * The "Contrib apps" component would be made redundant and new components for each missing contrib app (e.g. contenttypes, sitemaps) would be added. Also, for readability's sake, "django.contrib.foo" would be renamed to simply "contrib.foo". * For consistency, the "Authentication" component would be renamed to "contrib.auth", and "RSS framework" to "contrib.syndication". * Consolidate "django-admin.py", "django-admin.py inspectdb" and "django-admin.py runserver" into one component (called "Management commands" perhaps?). * Rename "Django Web site" to "Djangoproject.com Web site" * Lastly, potentially the most controversial change: for clarity's sake, rename "Core framework" to "Core (Other)", "Cache system" to "Core (Cache system)", "django.core.mail" to "Core (Mail)", and "Serialization" to "Core (Serialization)". Let me know if any of that is total yak shaving or if it's worth implementing. By the way, the reason why I care about this specifically is because I think that by making the component data more accurate and consistent, we'll drive in more useful contribution from people who feel they are expert or simply interested in specific areas of the codebase. Many thanks! Julien -- 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: Suggestion: a new "nature" field in Trac
Hello, I'm not sure if the consensus so far is either "Meh" or "Let's give it a try", or if there's even a consensus. I'm still keen on the idea but I don't want to insist too much if it doesn't gather enough support, so I'll re-submit it here one last time. The latest proposal is to introduce a new "Type" (or "Nature" or "Kind"...) field in Trac with the following options: * Uncategorized (default) * Feature request: for adding something new. * Bug report: for when an existing thing is broken or not behaving as expected. * Optimisation: for when an existing thing is not broken but could be made better, faster, stronger. * Other: none of the above. The idea is to prompt people to think more carefully about the nature of their request, and also to help focus on the relevant tickets when we enter feature-freeze. If we do want to give it a try, then it'd be great to implement it quite soon so we have enough time to trial it properly on our way to 1.4. If not, then no worries ;-) Cheers, Julien -- 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: Suggestion: a new "nature" field in Trac
On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote: > Hello, > > I'm not sure if the consensus so far is either "Meh" or "Let's give it > a try", or if there's even a consensus. I'm still keen on the idea but > I don't want to insist too much if it doesn't gather enough support, > so I'll re-submit it here one last time. The latest proposal is to > introduce a new "Type" (or "Nature" or "Kind"...) field in Trac with > the following options: FWIW, I agree it's worth doing. However, * I'd like to see some feedback from other core team members, and * I can't make these changes myself -- they require someone with access to the Trac install, and that isn't me. > * Uncategorized (default) > * Feature request: for adding something new. > * Bug report: for when an existing thing is broken or not behaving as > expected. > * Optimisation: for when an existing thing is not broken but could be > made better, faster, stronger. > * Other: none of the above. I would suggest two modifications to this: First, I would call "Feature Request" -> "New Feature" to remove any suggestion that just by opening a ticket, it will magically be implemented by the feature ponies. Second, this ontology doesn't do the one type of filtering that we need for release management -- identifying bugs that are release blocking. This means that either the 'bug report' category needs to be expanded into: * Bug * Bug causing data loss * Regression * Bug with new feature Or we need to add a separate boolean flag for "release blocker". We used keywords for the 1.3 release, and I think that proved a helpful resource; I think it's worth promoting these to full UI elements. 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: Suggestion: a new "nature" field in Trac
On Mon, Mar 28, 2011 at 2:28 PM, Russell Keith-Magee wrote: > On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote: >> Hello, >> >> I'm not sure if the consensus so far is either "Meh" or "Let's give it >> a try", or if there's even a consensus. I'm still keen on the idea but >> I don't want to insist too much if it doesn't gather enough support, >> so I'll re-submit it here one last time. The latest proposal is to >> introduce a new "Type" (or "Nature" or "Kind"...) field in Trac with >> the following options: > > FWIW, I agree it's worth doing. However, > * I'd like to see some feedback from other core team members, and > * I can't make these changes myself -- they require someone with > access to the Trac install, and that isn't me. Having said that -- I took a closer look at the Trac interface, and it looks like as of the recent update, I *can* introduce new ticket types without having access to the server. So, all we really need is some input from other core devs. 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: Suggestion: a new "nature" field in Trac
On Mon, Mar 28, 2011 at 2:31 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Mon, Mar 28, 2011 at 2:28 PM, Russell Keith-Magee > wrote: > > On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip > wrote: > >> Hello, > >> > >> I'm not sure if the consensus so far is either "Meh" or "Let's give it > >> a try", or if there's even a consensus. I'm still keen on the idea but > >> I don't want to insist too much if it doesn't gather enough support, > >> so I'll re-submit it here one last time. The latest proposal is to > >> introduce a new "Type" (or "Nature" or "Kind"...) field in Trac with > >> the following options: > > > > FWIW, I agree it's worth doing. However, > > * I'd like to see some feedback from other core team members, and > > * I can't make these changes myself -- they require someone with > > access to the Trac install, and that isn't me. > > Having said that -- I took a closer look at the Trac interface, and it > looks like as of the recent update, I *can* introduce new ticket types > without having access to the server. So, all we really need is some > input from other core devs. > > 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. > > I'm +1 on having more useful ways to filter tickets. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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: Trac components cleanup
On Mon, Mar 28, 2011 at 1:56 PM, Julien Phalip wrote: > Hi all, > > Now that 1.3 has been released (yay!), I'm reviving this thread to see > if we can make Trac a little more efficient on our way to 1.4. I'll > try to summarise what's been suggested so far in regard to improving > and clarifying the "Component" field: > > * The "Contrib apps" component would be made redundant and new > components for each missing contrib app (e.g. contenttypes, sitemaps) > would be added. Also, for readability's sake, "django.contrib.foo" > would be renamed to simply "contrib.foo". > > * For consistency, the "Authentication" component would be renamed to > "contrib.auth", and "RSS framework" to "contrib.syndication". > > * Consolidate "django-admin.py", "django-admin.py inspectdb" and > "django-admin.py runserver" into one component (called "Management > commands" perhaps?). > > * Rename "Django Web site" to "Djangoproject.com Web site" > > * Lastly, potentially the most controversial change: for clarity's > sake, rename "Core framework" to "Core (Other)", "Cache system" to > "Core (Cache system)", "django.core.mail" to "Core (Mail)", and > "Serialization" to "Core (Serialization)". > > Let me know if any of that is total yak shaving or if it's worth > implementing. By the way, the reason why I care about this > specifically is because I think that by making the component data more > accurate and consistent, we'll drive in more useful contribution from > people who feel they are expert or simply interested in specific areas > of the codebase. As with the other thread on Trac changes -- I agree this is worth doing, but would like to hear some other core dev voices before making any changes. 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: Suggestion: a new "nature" field in Trac
On 28 March 2011 17:28, Russell Keith-Magee wrote: > > * Uncategorized (default) > > * Feature request: for adding something new. > > * Bug report: for when an existing thing is broken or not behaving as > > expected. > > * Optimisation: for when an existing thing is not broken but could be > > made better, faster, stronger. > > * Other: none of the above. > > I would suggest two modifications to this: > > First, I would call "Feature Request" -> "New Feature" to remove any > suggestion that just by opening a ticket, it will magically be > implemented by the feature ponies. > +1, that's even clearer. > Second, this ontology doesn't do the one type of filtering that we > need for release management -- identifying bugs that are release > blocking. This means that either the 'bug report' category needs to be > expanded into: > * Bug > * Bug causing data loss > * Regression > * Bug with new feature > > Or we need to add a separate boolean flag for "release blocker". > > We used keywords for the 1.3 release, and I think that proved a > helpful resource; I think it's worth promoting these to full UI > elements. > I think there will rarely be many blockers at any given time, so I'd rather keep all bugs under "Bug" to keep the dropdown box succinct, and introduce a new "Release blocker" flag which will be enough to get people's attention. Whether it's a regression, bug in new feature, etc. can then easily be guessed by reading the ticket comment thread. Julien -- 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: Trac components cleanup
On 03/28/2011 02:33 AM, Russell Keith-Magee wrote: > As with the other thread on Trac changes -- I agree this is worth > doing, but would like to hear some other core dev voices before making > any changes. These changes look to me like a gain in sanity on every front. +1 Carl -- 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.
