Hey!
I think I've found a bug in flush command, but I'm not sure (maybe I don't
understand Django ethos?) so I'm writing here.
I have multiple databases (PostgreSQL) and multiple apps in my projects.
I'm using Django v1.5.1.
Models are routed by my specific database router, so some apps are
Hello,
After sereral minutes while using new Django (1.7) in DEBUG mode, I've got
enigmatic error on the screen: "A server error occurred. Please contact the
administrator."
This message is shown when another exception is raised within
django.core.handlers.base.handle_uncaught_exception.
What
Ok, I'll do it tomorrow.
On Sunday, September 28, 2014 5:35:31 PM UTC+2, Florian Apolloner wrote:
>
> Hi Marcin,
>
> can you please open a ticket for this? If you are up to it, a patch with
> tests would be superb!
>
> Thanks,
> Florian
>
> On Sunday, September 28,
Hello!
I'm using Django as a part of bigger stack where I'm using external tool to
manage database migrations.
After migration to Django 1.7 I'm encouraged at every runserver command to
execute some migrations, which may blow my databases.
I want to bypass Django migrations to prevent any
ill stop trying to change their
> schemas (including stopping making migrations for them).
>
> Andrew
>
> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak <marcin@gmail.com
> > wrote:
>>
>> Hello!
>>
>> I'm using Django as a part of bigger stack
On Tuesday, December 16, 2014 1:49:53 PM UTC+1, Andrew Godwin wrote:
>
>
> Also bear in mind that, by doing your own schema management for the
> contrib apps, you're kind of implicitly forking the schema; Django 1.8 will
> ship with some migrations for these apps, and you're going to have to
On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote:
>
>
> As far as I understood, Marcin wants to treat *all* models as unmanaged;
> there
> are no managed models to reference the unmanaged ones.
>
I would like to disable/remove/kick-off built-in migration mechanism. :)
If
Hi.
Just give people possibility to disable migrations functionality (remove it
from core and put as a contrib app, if needed).
/BR
Marcin
On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote:
>
> Aha! Then, I would suggest redesigning MigrationRecorder to only make the
>
Simply do not use Django builtin migrations. Consider using Liquibase
(maybe with Liquimigrate wrapper for Django) and feel freedom.
BR
Marcin
On Thursday, October 30, 2014 at 4:47:18 PM UTC+1, Peter Coles wrote:
>
> Hey all,
>
> I'm interested in getting database migrations to support setting
deconstruction.
>
> /Markus
>
> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak <marcin@gmail.com
> > wrote:
> >Hi.
> >Just give people possibility to disable migrations functionality
> >(remove it
> >from core and put as a contrib app, i
On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote:
>
>
>>
>> *What is the new way to dump the sql schema of currently installed django
>> appz ?* It'd maybe be worth that I provide a doc patch to inform users
>> about it.
>> *If there is none, is there an agreement to
with v1.8)
/BR
Marcin
On Friday, May 29, 2015 at 6:38:11 PM UTC+2, Tim Graham wrote:
>
> There's a ticket waiting someone to implement what has been discussed:
>
> https://code.djangoproject.com/ticket/24481
>
> On Friday, May 29, 2015 at 12:05:48 PM UTC-4,
, Marcin Nowak wrote:
>
> Thanks, I didn't saw it.
>
> But I've found quick ad-hoc solution using monkey patching.
> Just include this snippet in project`s __init__:
>
> from django.core.management import sql
>
> def check_for_migrations_bypassed(*args, **kw):
> pas
On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote:
>
> They were dropped as part of the removal of the old code that supported
> syncing apps without migrations.
>
But you removed a feature, not just old code.
In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was
Hello,
I'm working on a project which is based on Django`s internal migrations.
Sometimes when switching between branches (not sure for 100%), Django
complains about changes in my models.
When `makemigrations` command is executed Django generates migrations in
external (reusable) app placed in
ations command line? Are you using something like --noinput?
>
> Andrew
>
> On Wed, Jul 15, 2015 at 3:16 PM, Marcin Nowak <marcin@gmail.com
> > wrote:
>
>> Hello,
>>
>> I'm working on a project which is based on Django`s internal migrations.
>> Sometim
s list
> to the migration system in the meantime if you want to avoid this. There's
> no other real fix for this right now.
>
> Andrew
>
> On Wed, Jul 15, 2015 at 5:53 PM, Marcin Nowak <marcin@gmail.com
> > wrote:
>
>> Hi Andrew,
>>
>> I thin
> communicate interdependent changes to human in textual/graphic form were
>> unsuccessful, hence the current method of just doing everything for you as
>> best we can.
>>
>> As for a short-term fix, Collin's idea of importing the choices into the
>> migrat
I would like to set something like MIGRATION_MANAGED_APPS = (...) in my
project`s settings.
Every not listed app should not be inspected and should be excluded when
calling `makemigrations` command.
Setting MIGRATION_MANAGED_APPS to None (default) should enable backward
compatibility.
On 17 July
Sounds enough good. One important thing for me is that I have many of
external apps and few in project managed by me. Reconfiguring most of apps
just to tell Django "leave them alone" sounds like an overhead. That's why
I would like to tell Django "here are my apps, manage them please".
BR
Marcin
Hi,
I need to upgrade project to Django 1.8 but the SystemCheck Framework
bothers me.
It complains about thigs that should work, even if they are a little tricky.
I need to disable system checks designed for blogs and other simple sites.
How can I do that?
Best Regards,
Marcin
--
You
Thanks, Carl. I know about silencing but I want to disable unwanted
"feature". Working with Django is getting harder with every new version.
On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>
>
> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak <marcin
haps if you took some time to
> justify why users other than yourself might want to disable the check
> framework, it'd be easier to start looking at solutions to problems.
>
> Cheers
>
>
> On Wednesday, 5 August 2015 01:16:21 UTC+10, Marcin Nowak wrote:
>>
;
> On 5 août 2015, at 11:09, Marcin Nowak <marcin@gmail.com >
> 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
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 <marcin@gmail.com
> > wrote:
>
>> Hi Aymeric,
>>
>> This project is complex, as I said bef
PM UTC+2, Florian Apolloner wrote:
>
> 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 possi
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
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
>
On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote:
>
> Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods
> so they are applied before the system check framework is invoked?
>
I'll try that, thanks. To be honest I should remove monkeypatching, I don't
and not tested)
>
> We recently decided against shipping compatibility wrappers with Django
> because the interaction with the deprecation policy is messy. However, like
> Tim said, we're trying to make it easier to have such wrappers.
>
> --
> Aymeric.
>
> Le 5 août 201
gt; I'd be more open to it.
>
> SILENCED_SYSTEM_CHECKS = ['admin.E108', 'admin.E304', 'fields.E305',
> 'admin.E116', 'fields.E306', 'fields.W342', 'fields'W340']
>
> On Friday, August 7, 2015 at 4:35:37 AM UTC-4, Marcin Nowak wrote:
>>
>>
>>
>> On Thursday
Thanks for replies, Carl, Adam, Shai.
But I think you're worrying too much for too many things. You're trying to
control everything, trying to replace automated tests with system check
framework, trying to block "invalid" operations, etc, etc. This is bad way,
IMO.
Let's see a small example
On Tuesday, August 25, 2015 at 3:59:20 PM UTC+2, Aymeric Augustin wrote:
>
>
> There’s an obvious bug here: silenced checks are still printed out — even
> though they don’t prevent Django from starting.
> I hadn’t understood that from your earlier messages. It shouldn’t be very
> hard to fix.
On Tuesday, August 25, 2015 at 4:51:51 PM UTC+2, Carl Meyer wrote:
>
>
> I think likely the root problem here is that your monkeypatch is in a
> module which is not imported when validation runs. If I were you, I'd
> make sure that your `admin.py` imports whatever module does the
>
>
>
>> I think likely the root problem here is that your monkeypatch is in a
>> module which is not imported when validation runs. If I were you, I'd
>> make sure that your `admin.py` imports whatever module does the
>> monkeypatching, and then I'd expect this error to go away.
>>
>
> Yes,
On Wednesday, August 26, 2015 at 9:08:16 AM UTC+2, Florian Apolloner wrote:
>
> Ups, not enough coffee yet, the admin.ready() just registers the checks,
> it does not execute them, so order should not matter -- I shall close my
> browser now and get some coffee :D
>
I don't know how exactly
On Thursday, August 27, 2015 at 3:09:06 PM UTC+2, Tim Graham wrote:
>
> I created a ticket and pull request for the silencing of error/critical
> messages:
> https://code.djangoproject.com/ticket/25318#ticket
> https://github.com/django/django/pull/5197
>
>>
>>
Thanks, Tim!
Marcin.
--
You
On Thursday, August 27, 2015 at 9:43:40 PM UTC+2, Alexey Zankevich wrote:
>
> For such cases it's great to have DSL to build SQL queries, but it's a big
> question how low- or high-level language should be.
>
Take a look at SQLAlchemy`s expressions API. The ORM is built top of it.
I think that
As I said some time ago - there should be a possibility to disable system
checks (generally), and run them only when needed (i.e. by adding
--system-check argument to mgmt command(s)).
Kind Regards,
Marcin
On Tuesday, October 20, 2015 at 12:02:31 PM UTC+2, Shai Berger wrote:
>
> Just
On Tuesday, November 3, 2015 at 5:17:32 PM UTC+1, Asif Saifuddin wrote:
>
> I would like to create an experiemental repo on my github for
> experiementing the sqla support to django orm, hence some useful resource
> indicator would be great. sqla have core engine and orm on top of it, so
>
On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>
> sorry if this is a stupid question, but after having read
> https://code.djangoproject.com/ticket/5763 and the discussions linked
> from it, why should __ne not be implemented?
>
>
Because Django ORM __ne SQLAlchemy.
Hi all,
On Wednesday, April 13, 2016 at 9:58:18 PM UTC+2, Carl Meyer wrote:
>
> Hi James et al,
>
> In general, I like the idea of adding a helper to Django to read
> settings from the environment. I think this helper should be kept as
> simple and non-magical as is reasonable. Thus:
>
> This
On Saturday, June 4, 2016 at 12:12:42 AM UTC+2, Cristiano Coelho wrote:
>
> Aymeric, I have never said anything about connection pool, I'm talking
> about thread pooling to perform async work
>
I have similar requirements and issues with Django. It looks like it is
completely unreliable in
> From version to version it turns more into handy tool for blog
> creators/webdesigners
>
Don't get me wrong. For smal/short-term projects (up to 1-2yr of operation)
I'm still using Django and I would recommend it everyone for that kind of
job.
For long-term projects the first thing that
I can give you many reasons and many details, but I know you will not agree
with my conclusions. I remember what you (or someone from the team) said
about my ideas. I've shared them already and someone told me why you've
decided to do it that way, and why you wouldn't change it. I'm respecting
On Tuesday, June 21, 2016 at 3:28:26 PM UTC+2, Tim Graham wrote:
>
> Marcin, what are you hoping to accomplish with your latest mail? As
> Aymeric said in another thread, repeated complaining is not going to help.
>
Sorry for that. I'm just overhelmed and tired of "fighting" with missing
On Monday, June 1, 2015 at 5:11:27 PM UTC+2, Andrew Godwin wrote:
>
> OK, so I've just gone ahead and done the initial work on this:
> https://github.com/django/django/pull/4729
>
>
They shot not only in my head -
http://stackoverflow.com/questions/35455706/equivalent-of-sqlall-in-django-1-9
On Tuesday, June 21, 2016 at 2:34:11 PM UTC+2, Aymeric Augustin wrote:
> Regarding database connections, if you weren’t using Django, you’d have to
> create a database connection with something like `psycopg2.connect()` and
> dispose of it with `connection.close()` when you no longer need
On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote:
>
> No, it's not as simple as reverting the removal commit [0]. All the legacy
> schema generation methods are removed too [1].
>
We don't want to add them back
>
I know.
> but rather use the SQL generation from the
On Tuesday, June 21, 2016 at 10:55:13 PM UTC+2, Marcin Nowak wrote:
>
>
> Somebody wrote eariler that `sql*` commands can be written as an external
> app/package. They can't. Django internals must be fixed before this, or new
> app must provide complete solution including sql ge
>
>
> You can write the "sqlall" you want as a shell script -- remove any
> existing
> migrations, use "makemigrations" to create an initial migratgion,
Not exactly. I'm not using migrations [.. cut ..]
I repeat Aymeric's advice that spreading your frustrations over this
> mailing
>
On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote:
>
>
>
> On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote:
>>
>> No, it's not as simple as reverting the removal commit [0]. All the
>> legacy schema generation methods are remove
>
>
> So add another step in the end to remove the temporary migrations folder
> created just in order to enable sqlmigrate. If you're a real purist, add
> yet
> another one to make sure you don't have a django_migrations table left
> over.
>
>
Sorry, Shai, I doubt you understand the
On Tuesday, January 5, 2016 at 5:29:14 PM UTC+1, Tim Graham wrote:
>
> This came up in a ticket a couple days ago:
> https://code.djangoproject.com/ticket/25995
>
>>
>>
May I ask why this ticket was resolved just by adding some information to
the documentation?
I do not understand why some
>
>
>
> It's not resolved - the ticket is open, and Accepted.
>
>
Thanks. I've seen comment with status set to closed and I didn't notice the
current.
My fault.
Marcin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django
On Thursday, June 23, 2016 at 12:12:51 AM UTC+2, Shai Berger wrote:
>
>
> Thanks for this thoughtful clarification. I think I understand your
> position
> much better now. If
Thanks for reading, Shai. I know my English is far from perfect, so I
appreciate your involvement.
I understand
Hi all,
Here is a file which breaks installation on fresh Debian system:
https://github.com/django/django/blob/master/tests/staticfiles_tests/apps/test/static/test/%E2%8A%97.txt
I'm using Buildout and virtualenv with Python 2.7.9.
The full traceback is:
Traceback (most recent call last):
>
>
>> I'm using Buildout and virtualenv with Python 2.7.9.
>>
>>
> and setuptools 25.1.2
>
>
It works with setuptools 17.0, but displays warning:
Getting distribution for 'Django==1.8.14'.
'tests/staticfiles_tests/apps/test/static/test/⊗.txt' not ANSI_X3.4-1968
encodable -- skipping
warning:
On Tuesday, July 26, 2016 at 11:16:18 PM UTC+2, Aymeric Augustin wrote:
>
>
> Specifically, please explain why this has to live in Django.
Because Django has an implementation which can be extended without
rewritting a whole thing from scratch?
Well... it is your decision about "including
Dear all.
I would just say that implementation of SelectMultiple.value_from_datadict
is not based on duck typing, and has some disadvantages.
Source:
https://github.com/django/django/blob/master/django/forms/widgets.py#L606
def value_from_datadict(self, data, files, name):
if
Hi all.
Sometimes there is huge amount of related objects. In the effect there is
no possibility to delete a model because of http timeout error.
Displaying objects to be deleted is quite nice feature, but just unusable
in cases like that.
Another thing is that nobody will read 74k related
>
>
> Anyway, I don't want anyone to think that I complain as I don't have the
> resources to write yet another migration tool and both South and Django
> migrations beat writing SQL by hand.
>
Have you tried Liquibase ever? It is very reliable, unfortunatelly it is
missing automatic
>
> Have each Field class deconstruct to a field name and params [...]
Thanks, @patrys. A field deconstruction is a key to achieve what I tried to
describe earlier.
We can discuss the details about implementation, but this is not important
now.
Marcin
--
You received this message
>
> Understand when I say that what you are proposing is a very, very big
> change. Django's ORM is heavily coupled to runtime information and the app
> layer, and I tried for many years to decouple them and ran into all sorts
> of issues as a result. Importing the fields from the source code
>
>
> Some of these are problems, yes, but you have to understand they are
> tradeoffs and the alternative is, in my opinion, worse.
>
>
Yes, I understand. But maybe there is another / better alternative.
Let's simplify a little and talk about a python deps first.
> > I believe that there
Hi.
At the begining please forgive my engilsh - i'm not a native speaker.
I wrote here and in other places my thoughts about db migrations few times,
and probably Tim remembers me so well.
My opinion was not changed, but I realized that I cannot leave Django
ecosystem for a long time.
In that
*About database agnostic migrations.*
Liquibase is a tool which is decoupled from the app layer and gives a
possibility to write agnostic changesets.
To be independent you must use builtin operations and narrow used field
types to "well known" subset
Hi.
Fix of #24483 breaks possibility to declare dynamic choices for model's
fields.
I read the ticket and I understand the initial problem, but it was used
frequently to support dynamic choices.
Now we have always consistent but static choices, tests are passing,
migrations have consistent
W dniu czwartek, 29 marca 2018 19:28:39 UTC+2 użytkownik Michael Grijalva
napisał:
>
> Yeah seems like `db_default` was the felling, at least last time I scanned
> through this long-going discussion :D
>
> I've had to tweak Django's migration handling a bit to handle our
> zero-downtime
BUMP
--
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
>
> Fix of #24483 breaks possibility to declare dynamic choices for model's
> fields.
> I read the ticket and I understand the initial problem, but it was used
> frequently to support dynamic choices.
>
> Now we have always consistent but static choices, tests are passing,
> migrations have
W dniu wtorek, 24 lipca 2018 14:43:51 UTC+2 użytkownik Ramiro Morales
napisał:
>
> Marcin,
>
> You have upgraded recently to version 1.11.13?
>
>
About month ago. It was litlle painful process, BTW.
> IIRC handling of percent symbols in translatable literals has been the
> subject of a few
Hi.
I'm not sure what is going on, but I've updated recently Django to 1.11.13
and two things seems to be broken (from my perspective):
- behaviour of translation messages containing % is inconsistent, for
example:
- prevously used msgis are staying untranslated with
Hi Aymeric.
Thank you for your reply.
Unfortunately you wrote mostly about me or my writing style, not about the
issue.
I disagree with your opinion about my comments being passive or aggressive.
I'm always writing about a piece of code, functionality,
design/architecture or bug. I never
> You can simply do that by including a gettext_noop('your custom string')
> line anywhere in your code (or in a specific file you create for that
> purpose).
>
>
This is an ugly workaround. Makemessages has other issue - it grabs
messages from external eggs/packages, which are found in
Hello.
There is a huge issue with content types framework. The data is loaded
after every migration (post_migrate signal) automatically, and this
approach is against db data consistency.
The biggest problem is with data migrations, which are applied at the first
time (on clean database). Any
]
>
> Wouldn't a workaround be to call create_contenttypes() in a RunPython in
> your app's migration before inserting the data which depends on the content
> types?
>
>
Thanks, but as a workaround you can do almost everything. My post is about
proposal of fixing the issue.
BTW: RunPython() is
Hi Arthur.
BTW: RunPython() is another thing, which can break your migrations, and
should not be used (especially not by Django internally), because it relies
on the application layer.
How else can you do a data migration? There is no
> `migrations.InsertIntoTable`,
>
You're right. That's
Hi.
I'd ask about "models.E026: The model cannot have more than one field with
primary_key=True".
It's not a true. The table or view *can* have more than one *column* as a
part of a primary key.
It's pretty common, when you have views with cross joins or unpivots.
I can add models.E026 to
to allow inserts (new object saves) to work, splitting the parts
> back out.
>
> If you try this, let me know.
>
> Thanks,
>
> Adam
>
> On Wed, 1 Apr 2020 at 11:34, Marcin Nowak > wrote:
>
>> Hi.
>>
>> I'd ask about "models.E026: The model cannot hav
Hi.
My question is about these two:
https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L55
https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L64
Both are loose cannons. All dependent objects are silently destroyed during
dropping table
81 matches
Mail list logo
