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
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 examp
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 mode
> > 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.
M
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. Sinc
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
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 commi
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
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 bui
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 productio
10 matches
Mail list logo
