Hi Marcin,
Thanks for the clarification, that's helpful.
The backwards compatibility wrapper looks like this in this case:
@contextlib.contextmanager
def commit_manually(using=None):
transaction.set_autocommit(False, using)
try:
yield
finally:
transaction.set_autocomm
On Wednesday, August 5, 2015 at 7:42:16 PM UTC+2, Tim Graham wrote:
>
> There is a check a few lines above the snippet you linked for
> "allow_migrate_model('other', Permission)". Is that returning the correct
> result? I don't think you can create permissions in the 'other' db without
> conte
If you have a big need to use old APIs, feel free to implement them in your
own package or even in a reusable app so that others can benefit too. There
have been other efforts like https://github.com/arteria/django-compat to do
so. We can't maintain them forever, lest Django become bloated and
There is a check a few lines above the snippet you linked for
"allow_migrate_model('other', Permission)". Is that returning the correct
result? I don't think you can create permissions in the 'other' db without
content types since they are linked by a foreign key.
p.s. "Is it a bug" questions s
Hi, it's me again.
I'm managing migrations myself without using builtin migrations.
My project is using many databases and I'm calling schema migration
separately for each database, providing database alias as a command
argument.
I'm also emitting pre- and post- migrate signals.
The problem i
No, there is not problem in this code only, but yeah - it is a big problem.
Real problem is that newer versions of Django are pushing developers to do
things by the only one way, which is good for blogs or cms, or maybe new
and small projects. As the result it is getting harder to maintain compl
On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote:
>
>
>
I must try to do replacement or bring old behaviour of commit_manually()
> with my custom wrapper. I'm trying to change code as less as possible.
>
To be honest the "issues" you outlined here seem to suggest a bigger
pr
It's ok. I think that the thread can be closed, except the suggestion of
making compatibility layer, which is rather a kind of Django`s philosophy
and may be continued in a new thread (if needed).
On Wednesday, August 5, 2015 at 4:08:53 PM UTC+2, Carlton wrote:
>
> Sorry to be a pain but, coul
Hi Josh,
thanks for your reply. I was a little bit afraid of making PRs of
interviewed code. So I made it now and the PR is
here: https://github.com/django/django/pull/5108
Dne středa 5. srpna 2015 3:15:22 UTC+2 Josh Smeaton napsal(a):
>
> Hi Petr,
>
> Thanks for working on that ticket. I'm pro
Sorry to be a pain but, could this thread be continued (if it's going to be) on
Django Users?
(sorry)
—
On Wed, Aug 5, 2015 at 3:59 PM, Marcin Nowak
wrote:
> Hi Aymeric,
> This project is complex, as I said before, and works well with Django 1.4.
> But we need to upgrade it to newer ver
Hi Aymeric,
This project is complex, as I said before, and works well with Django 1.4.
But we need to upgrade it to newer version because of lack of support,
security issues, and simplifcation of maintenance and growth (we're
currently using three different Django versions, from 1.4 to 1.7, and
On 5 août 2015, at 11:09, Marcin Nowak wrote:
> I'm using commit_manually() frequently, but this decorator was removed...
Hi Marcin,
Sorry for derailing the discussion a bit, but could you clarify why you were
using this API? I removed it after failing to find a use case where it would
be pref
Thank, Josh.
I'm upgrading mature and complex project, which have some tricky parts
implemented like a monkey-patched user model, which is applied after system
chceck execution. So Django complains about missing fields in ModelAdmin,
but patch works fine. There were some complains about doubled
13 matches
Mail list logo