Re: Turn off migrations completely in Django 1.7
On 25 August 2015 at 14:32, Avraham Serour wrote: > > We're working with databases and their representations in application > layer, and not vice versa. > > Speak for yourself, I'm working with the models, saving them in the > database is just an implementation detail > I'm speaking on behalf of a one of experienced developers, who knows that data is most important thing in IT. And this is not an implementation detail, because the bulit-in tool is forcing us to do things in the your way/workflow, and sometimes blocks us. Let the user decide which tool is better for his job. Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CwT%3Dp%3Dke6P6iKvQkHufTQ14WAD_KVM92ni4NfbrLxhEGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 25 August 2015 at 16:21, Tim Graham wrote: > What does "turning off migrations" mean in practice? Is it not enough to > avoid the makemigrations and migrate management commands? Currently I'm replacing mgmt commands to avoid accidential calls, and also replacing test runner. But, for example, `runserver` complains about unapplied migrations (which is not true), and I don't know what else and when other db alterations can be executed. "Global turn off" should give us assurance that nothing would be changed in db automatically. BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CxBWsouYWmASv1gXQ%3DHyyqjnNenspkztv%3Dzv_f4P0uuZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 25 August 2015 at 16:53, Carl Meyer wrote: > I thought we already covered this topic, and `managed=False` should work > for your use case. That's the exact meaning of this flag: "I don't want > Django to manage my database, please never touch it." Have you tried > adding that flag to your models? Does something about that not work for > you? > Managed=False is not same. I.e. I can't set managed=False for 3rd party apps (including `django.contrib`) But to be honest I didn't tried iterate over all INSTALLED_APPS to patch meta options... BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CyVB06KZKXXtFiwZpBTgEkt4n0q5r%2BVwo-V4d29XWNy9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
> > Maybe there is a solution for both? > > Sometimes when you have unusual requirements you have to do a little > more work to meet them. To my knowledge, out of the many hundreds of > thousands of Django users, you are the first and only one to request a > way to turn off migrations entirely. Maybe no one else talks about it. I don't believe that there are no other database-centric projects, where Django is used to map (external) database tables to objects and generate some HTML or RESTful output. > It is not possible to build a framework where _everything_ is easy. We > aim for "Simple things should be easy, advanced things should be possible." > > Well.. I would like to do something as hard as usual, but turn off some unnecessary stuff. Same as not including "django.contrib.admin" in INSTALLED_APPS, same as switching template engine to Jinja2, or same as removing unnecessary middleware. I just thought that skipping some function calls is simplest than creating new feature for building workarounds, and even will be shorter than time for talking about it. But I was wrong. BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CzEFcvjOO9685rQ5cqV6oo08a%2BzVs-%2BmkEqu%3DBZ4bFf7w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 25 August 2015 at 17:04, Carl Meyer wrote: > Hmm, yes, third-party apps are an issue. > > My recollection from the last time you brought this up is that we > decided an AppConfig-level setting to do the equivalent of managed=False > for an entire app would be a reasonable feature request. Since you can > provide your own AppConfig for third-party apps, this would cover that > use case, too. > That would be a better than nothing and it's flexible. But in the most of my cases I will need to provide app configs for all apps. This can mean a lot of unnecessary work. Something like 'disable all' is simplest solution, but naturally limited. Maybe there is a solution for both? BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CxVLc1MAYJT1f0h7DjwJGwkjqs3Ksvb%3D4bpi%2Bjiq7MbMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 25 August 2015 at 18:44, Marcos Eliziario wrote: Changing the database accidentally can be avoided simply by adjusting the > privileges of the database user django uses. It's not perfect. The connection requires write access and Django inserts some data automatically. But table-level grants can be a paritial solution. And still Django complains about unapplied migrations... The thing is, nobody ever requested that, it is not a popular feature > request, so, it is not there and won't be there unless someone contributes > with a solid patch and a solid case for this added complexity I would like to provide solid patch as a pull request, but I'm afraid that it will be rejected due to some kind of spirit, politics or something else. BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7Cyn4rTb-8Y5QJynjhd4puYDVwNv4FaKay446J7W%3DvGUmw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 26 August 2015 at 16:50, Carl Meyer wrote: > At this point the discussion belongs on the django-developers list, to > enumerate the real-world use cases and sort out the pros and cons of the > various possibilities. Getting a change into Django is rarely > impossible, but it does require committing some time and energy to > discussion and evaluation of the options. > I can specifiy some use cases. 1. Using Django as a part of bigger stack, where databases are maintained by external tool and no schema nor data modifications should be applied automatically. 2. Avoiding limitations/forcings of builitin migration system and Django ORM. By using external database migration tool developers have flexibility and possibility to "do things right" (from db perspective). Models are used as an read/write interface with a subset of fields. Anf it was working good up to 1.7, and may work good with migrations turned off. 3. https://code.djangoproject.com/ticket/23159 Wontfix, because does not fit design concepts of *migrations*. Without migrations everything is OK and works as expeced. In that case migrations are not feature but a real limitation. And last, but not real use case (just design concept): 4. Improper migrations design Django migrations are apps-related, same as South was. This is a not the best possible design. There is, for example, possibility to generate migrations within python eggs (even in Django itself). Migrations should be project-wide and splitted by database. Developer should have possibility to change database schema as he need without forcing limitations of model-based migration system. Not every table is mapped to model. Kind Regards, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CzKoSezwPMgQk3MZe9R-1JcmF6wA6n756tS5UBXOPR12g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django 1.7 migrations: Adding one field to User`s model
On 26 August 2015 at 20:09, Hugo Osvaldo Barrera wrote: > Oh, so the field you're adding in monkey patching contrib.auth.User? > IMHO, the design problem isn't django, but rather monkey-patching models > itself. Maybe you'd be better of using a custom user model. > I've tried to use custom user model, but Django forces me to change all FK`s. This is not possible for now. I need to add just one column / field to existing User model. Nothing more, nothing less. AFAIK I should create profile for user and put this column into profile model, but there are two disadvantages: - the profile is not necessary now and will contain just one column (well, three when incl. PK and FK to user) - performance issues (joining table) I think that for this use case "Custom user" will not work. I was wrong. I must forget about "Custom user". ;) BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CzRVk%3DG-8JzHECbEH%3DZueP3BibBxZkV-vurBp3ND1aaZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 21 April 2016 at 10:06, wrote: > Either way - we recently hit another Django limitation - as best I've been > able to tell, joining a table with itself seems to be very poorly supported > - so we're heading towards SqlAlchemy, and probably away from Django > altogether in time. If you're building some report-like queries, or any static queries, I would suggest to use raw sql. You can optionally wrap results with model instances using Model.objects.raw(). Previously I used SQLAlchemy together with Django, but currently I'm moving from SA to templated raw queries, because building them using any ORM is too hard to maintenance (code is very unreadable in opposite to plain SQL). But embedding raw queries in Python code is generally bad, same as mixing Python together html (spaghetti code). That's why I'm working on SQL templating module based on Django` template engine. If you're interested please look at https://github.com/marcinn/django-sqltemplate/ (please note that is a alpha version, which may be unstable and API may be chaged). The main advantages of raw SQL are readability and no limits. Templated SQL gives you possibility to modify queries based on context variables, which is not flexible as querysets, but often good enough to do job well. But as a disadvantage you have to pay attention to SQL syntax and variables escaping. Kind Regards, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7Cx%3D2AXJHGGLSt%2B1fhNPoJRJ2rKLdWnsW4uD0gZR4fJP%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Turn off migrations completely in Django 1.7
On 22 April 2016 at 02:02, wrote: > Yeah, good call perhaps. We're certainly drawn to raw sql (which we all > know fairly well) compared to learning Django's tricks for complex queries, > but the originator of our project chose to write lots of unit tests using > sqlite (instead of our production mysql) for speed and simplicity reasons > (notwithstanding questions of incompatibility) - so an ORM offers some > extra value currently due to SQL differences that can be handled > automatically. On first glance SA appears a little more like SQL than > Django's query language - though I'm sure there's times when I may tear my > hair out wanting raw SQL. If may suggest something.. sqllite with :inmemory: backend will improve speed of tests, indeed, but you will be still limited in expressing yourself because of dialect differences. You will need to "speak" using "common words" and drop away power of the specific database engine. SQLAlchemy has a marvelous expressions API, it covers more features than Django, but also it allows to build queries with direct embedding SQL literals and even parts of the query (`sqlalchemy.text()`). So it is a matter of time when your queries will become dialect-specific. Or your unit tests will block you get the things done... In my tests I'm using many database engines. Many of tests are non-transactional, i.e. using django.test.TestCase as a base class (where every test starts with `BEGIN` and ends with `ROLLBACK`). And the most time-consuming operations are cleaning databases and loading fixtures for every test. So I removed them by overridng some of Django`s methods. I'm using factories instead of fixtures and ROLLBACK-ing after every test to avoid slow cleaning. As a result test suites are running quite fast without switching to SQLite, so I don't have to wrap everything into ORM and I can use specific features of each db. Kind Regards, Marcin -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CwOZBJyDHiE-B_3FMZa6PA6rTnzprbuKwi2OEtCMtg6ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
