Yes, the large number of weird things people need custom SQL for is why I
want to push for migrations much more overall - especially for cases like
post_syncdb (should be replaced by data migrations) and the arbitrary
initial SQL file support (should be replaced by custom migrations).
I don't plan
> During cache body creation, concurrent processes can also make useless
cache bodies in case usage tmp file (not locking).
-- sorry, during cache writing to tmp file...
2013/5/31 Ivan Smirnoff
> I was also created the backend, but did not have time to make a fork.
> See
> https://bitbucket.or
I was also created the backend, but did not have time to make a fork.
See
https://bitbucket.org/evotech/cache-tagging/src/d26adf9f66581923f03ca2d89261568b521eb82e/cache_tagging/django_cache_tagging/backends.py?at=default
Also, I think, it will be better to move directory clearing to Thread for
asy
I've created a ticket with a script that demonstrates the issue and
provides an implementation that uses werkzeug's tempfile approach
https://code.djangoproject.com/ticket/20536
Before I start forking on github I'd like some feedback on the ticket.
Thanks!
Op donderdag 28 maart 2013 01:23:52 U
On 31 touko, 15:51, Marc Tamlyn wrote:
> In particular I'd be quite strongly against the main Django codebase
> shipping with potentially broken drivers - this will reflect very badly on
> the project for new users.
The thing is, this is *already* true. Oracle GIS was badly broken in
1.4 release
On 31 touko, 16:58, Michael Manfre wrote:
> On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn wrote:
> > In terms of non-core backends (and I include Oracle in this) - my
> > preferred option would not be to include them all in core Django, but to
> > collate them in and manage them under the Django p
On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn wrote:
> In terms of non-core backends (and I include Oracle in this) - my
> preferred option would not be to include them all in core Django, but to
> collate them in and manage them under the Django project - i.e.
> github.com/django/django-mssql. Th
Hi.
I don't have any more arguments, and I agree with most of your criticisms.
However, I still think that the change of
get_template(template_name)
...
to
get_template(template_name*, dirs=None*)
...
template, origin = find_template(template_name*, dirs*)
(and similars in that module)
is a
In terms of non-core backends (and I include Oracle in this) - my preferred
option would not be to include them all in core Django, but to collate them
in and manage them under the Django project - i.e.
github.com/django/django-mssql. These are "looked after" by the Django
project to ensure tha
I'm really quite unconvinced by your arguments I'm afraid. In particular
one of the strengths of the normal template loader is that it does *not*
start locally - so I can use a pluggable application and override templates
very easily. The normal pattern for pluggable applications is that they
n
I have generally not kept my migrations so they always work from scratch
for similar reasons Luke said - Data migrations are often dependent on the
data in the site - this is particularly relevant to content-driven (CMSy)
sites where I may need to move a load of page about as a data migration at
On 05/31/2013 02:08 PM, Andrew Godwin wrote:
One problem with this is that you have to be careful to write
migrations
that will always work from scratch. This is best practice, but I
have on
occasion used data migrations that were for specific problems, and may
have depen
>
> One problem with this is that you have to be careful to write migrations
> that will always work from scratch. This is best practice, but I have on
> occasion used data migrations that were for specific problems, and may
> have depended on specific data in the database. I've also used them for
On 30/05/13 20:55, Andrew Godwin wrote:
> The way South works, and the way this will work (for new installs as
> well as tests) is that if migrations are present for an app, it will
> always create new databases by running through them from the very first
> migration to the latest one.
One proble
That's the nasty edge case - currently it just fails, in the new system
it'll generate three migrations (add A with no FK; add B with FK; add FK to
A). As for the previous post, the syncdb-like step will always run before
the migration step; thus, dependencies are allowed from a migrated to a
non-m
On 05/31/2013 09:55 AM, Mantas wrote:
Quoting django-developers@googlegroups.com (2013-05-31 07:39:24)
From: Andrew Godwin
Date: May 30 07:03PM +0100
Url: http://groups.google.com/group/django-developers/msg/137ab14f361fd052
2. Leave syncdb as it is, like South does, and have everything happen
16 matches
Mail list logo
