That'll definitely be there - South has never needed the frozen ORM, and
this won't either. If you want, you can just use sql: and depend:
stanzas in the new migration files, and write everything manually - and
you'll still get the benefits, like state tracking, transaction
management a
hat's only because it has to enact this system via
entirely third-party means. Once it's a part of the Field API, checking
if it's there becomes a lot simpler.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers&quo
that the case of a field being removed completely is rare enough
that this is acceptable (having to use a workaround). Most times a field
becomes unimportable it will likely have moved, in which case a good
number of apps would keep the old import working (as code probably
depends on it).
But ye
he full proposal for this - it's been a while since
I've heard rumblings about SQLAlchemy, and I've forgotten what the major
objections/drawbacks were.
It would certainly save me some work if I could rely on it for some DDL
code generation, though because of the way models are defined
one test function reference per line?
Not sure about having to read from stdin - I can see that potentially
interfering with things like pdb.set_trace() - but there's always the
option of adding a command-line flag too.
Andrew
--
You received this message because you are subscribed to the Google Gr
on newer ones.
Of course, this just leads to a higher limit after which you have
values which are too long, but if your class names are getting over
200 characters long I suggest you have other issues.
Andrew
--
You received this message because you are subscribed to the Google Groups
tting schema migration stuff in, it'll just take a
release or two till it's ready.
As for the interim solution, I replied to Stephan's post about that - I
think just increasing max_length will work well enough for now in this
case, as it's one of the few situations where the schema
ast year but unfortunately it's blocked on us improving
the template engine - it's too slow in the current one to be workable.
There was also a GSOC project that same year to make the templating
faster, but that unfortunately didn't result in something we could use.
Andrew
--
You re
ith what's there (mostly
due to having to fiddle with things like how fields specify types and
relationships and tables work).
Still, I'm +0 on the whole idea.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
ove to
outsource. Looks like there's still plenty of work to be done no matter
what happens.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To un
it). It should be good enough until I get the
migration stuff in, I'd say.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscrib
of
cleanup code!
Andrew
On Mon, Aug 20, 2012 at 2:49 PM, Rohan Jain wrote:
> Hi,
>
> Today is the 'pencils down' date for this GSoC project. Past 4 months
> have been a great learning experience from me. Just being in the
> context of security side of the web has been real
I can see a use case for this, but would this not work?
from django.db.models import get_model
post_save.connect(
my_signal_handler,
sender=get_model('my_app', 'MyModel'),
)
As long as the app cache has been initialised before you call get_model,
this should work fine.
- Andy
On 22
I'm definitely +1 on this - I have a few codebases I want to start
converting but also want to keep running on 1.4, and the patch looks
sensible to me. There is precedent for this, and even if there wasn't, this
is a nice way to get the migration cycle started.
Andrew
On Thu, Sep 6, 20
7;s/migrations' might get weird,
but then I do nasty things and that's my problem to fix.
Andrew
On Thu, Sep 6, 2012 at 4:35 PM, Anssi Kääriäinen wrote:
> On 6 syys, 19:17, Anssi Kääriäinen wrote:
> > I now have a pretty good WIP approach of tracking changes in testing.
&g
(by developing an app
that uses it, partially) and making sure that 1.5 ships with something
that's decently solid, and with an Oracle backend if I can get it working
on my machine.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers"
>
>
> Can you put this in a pull-request so I can comment inline?
>
>
I can indeed: https://github.com/django/django/pull/376
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send e
module, I'll let you know when I get
around to it.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send
ngo/commit/dbc17d035b255a4da977251fe399f5c80cffeecd
https://github.com/andrewgodwin/django/commit/49d1e6b0e20a363cbf9b105e8e6d3fc5fc1cad2f
The SQLite test suite all passes after these changes, so this is looking
good. Thoughts?
Andrew
On Tue, Sep 18, 2012 at 4:49 PM, Andrew Godwin wrote:
> An update fro
On 25 September 2012 17:45, Alex Ogier wrote:
> There's a big thing you cannot do without grouping models: you can't have
> an abstract base class relate to another abstract base class. Django's
> foreign key mechanism doesn't know how to relate to a to-be-instantiated
> concrete class.
>
Not en
solver, meaning 1.6 would ship with a full
migrations system in place.
Input on this plan is welcome - I just didn't want to rush something in
when it can be more polished and useful next release! It also means that
this can hopefully be integrated more smoothly with app-loading when that
la
commands like syncdb (so core would be cleaner).
Andrew
On Fri, Sep 28, 2012 at 3:22 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> On Fri, Sep 28, 2012 at 8:29 AM, Jacob Kaplan-Moss
> wrote:
> > On Fri, Sep 28, 2012 at 4:55 AM, Russell Keith-Magee
> > wrot
7;m hoping, in fact, that adding the database backends into core will make
anyone else who is doing custom migration stuff's lives easier - especially
if it's something highly custom internal to a company where you don't have
the time or team to do that stuff properly.
Andrew
On Thu, Oct
ugh this is the first time I've ever come across such a
problem so it might be a one-off.
Regards,
Andrew Ingram
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.
ass
It doesn't make a difference if the ManyToManyField is on the abstract model or
the concrete one.
Regards,
Andrew
On 4 Nov 2012, at 20:42, Mike Johnson wrote:
> Hi Andrew,
>
> I'm trying to come up with a test case for this and am struggling to
> reproduce the
The approach we take at work is to have a view that wraps around the
product, category and occasion views and takes care of the fallthrough
logic. I'm not a fan of this approach, because it means that you can't just
look at the urlconf and see which pattern maps to which view function. On
the other
On 29 Mar 2013, at 17:22, Bernhard Ja wrote:
> Hello together,
> this is my first post to the Django developers list. Please let me know if
> this topic is better placed on Django users :-)
>
> For i18n there is a javascript_catalog view we can use to access translations
> in javascript.
> Acc
On 10 April 2013 14:56, Javier Guerra Giraldez wrote:
> check django-storages
> http://django-storages.readthedocs.org/en/latest/ it includes several
> storage backends, S3 among them.
>
> --
> Javier
I think he was asking whether the storage API should be extended to
support additional operatio
scuss
the idea with you.
The official application period opens on April 22nd - I'll post nearer the
time with detailed application instructions.
This is the first year we're trying this widening of scope and we hope
it'll invite some exciting new applications. Many of Django's be
I've been wanting this exact feature for years. I've always struggled to
explain the problem, but I've had numerous cases where this would have made
for a vastly simpler template structure.
Big +1 from me.
On 17 April 2013 16:50, Emil Stenström wrote:
> Hi,
>
> Proposal:
> Make it possible to
The original use case for pk_url_kwarg and slug_url_kwargs was something
like this:
/(?P[\w-]*)/ - DetailView
/(?P[\w-]*)/another-resource/ - Scoped ListView
/(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped
DetailView
In this case, the Scoped ListView and Scoped DetailView would both inherit
a mi
it developed in a
reasonable way.
Andrew
On Sat, Apr 20, 2013 at 11:00 PM, Damian Skrodzki wrote:
> *
>
> Hi again.
>
>
> Let’s try analyse the topic Improved error handling a little deeper.
>
>
> I’ve found dozen opened issues related to bad error handling (these are
pdates are
(personal bias, I suspect)
- I'd like more details on what's been holding it back since GSOC 2011,
and how this GSOC is going to help serve those
Still, I like the general idea. You've mentioned tests and docs too. And I
really, really want to land this feature!
Andrew
ittle hard to understand sometimes so
please try and get an inital copy of your application in with plenty of
time to spare - you can always save new versions right up to the deadline.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django develo
On 30 Apr 2013, at 23:38, Shai Berger wrote:
> I see one issue with this: According to current procedures, if this timeline
> is followed, support for 1.4 will be dropped less than 6 months after the
> release of 1.5. At least for some of us (which, as I mentioned earlier on the
> list, only mo
On 1 May 2013, at 00:13, Donald Stufft wrote:
>
> On Apr 30, 2013, at 7:10 PM, Andrew Ingram wrote:
>
>> On 30 Apr 2013, at 23:38, Shai Berger wrote:
>>> I see one issue with this: According to current procedures, if this
>>> timeline
>>> is foll
On 1 May 2013, at 00:35, Carl Meyer wrote:
> On 04/30/2013 05:27 PM, Andrew Ingram wrote:
>> Absolutely, there's no requirement to migrate, but it does have the
>> feel of an weird kind of deprecation. Obviously there are
>> workarounds, like you said, I can upgra
ocus on what section of our user base it
will help. Deployment isn't something there can be a single solution (or
even pattern) for, and I think encouraging that could be a bad idea.
Andrew
On Wed, May 1, 2013 at 8:20 PM, Nate Aune wrote:
> Hi Russell and Florian,
>
> A bit late t
I'm happy with this - I doubt schema alteration will be mergeable by the
15th (though I'm trying to get something together for DjangoCon EU) and I
want to encourage smaller release cycles. And the new transaction stuff is
great, damnit, we should ship that.
Andrew
On Tue, Apr 30, 20
s so far this year,
I'm still trying to work out where to draw the boundaries with the new
rules.
Andrew
On Fri, May 3, 2013 at 8:57 AM, Nate Aune wrote:
>
> On Thursday, May 2, 2013 4:11:35 AM UTC-4, Andrew Godwin wrote:
>>
>> I feel like the deployment problem is one t
Just want to say that I'm happy with a "fast transition".
Is there a possibility we can detect the case where the tests might be
broken (how might they be?) and print a helpful error message?
Andrew
On Thu, May 9, 2013 at 11:51 AM, Russell Keith-Magee <
russ...@keith-magee.c
On 12 May 2013, at 00:55, Russell Keith-Magee wrote:
> I'm sure I understand this argument. Python objects are passed around by
> reference, not by value, so if you've passed in a Django object deep into
> another library, that library will be pointing at the same instance. If the
> instance is
e way back that perhaps we could derive the
random element from the migration name, making it different across
different migrations so they don't clash but still the same across runs,
but I'm not sure how you'd access that from within SchemaEditor)
Andrew
On Thu, Nov 20, 2014 at
bug) and it's a pretty small thing to backport
anyway.
Andrew
On Tue, Nov 25, 2014 at 8:23 AM, Markus Holtermann wrote:
> Hey Luke,
>
> It would be interesting to see why A.1 and B.1 depend on each other. If
> there are e.g. FK constraints pointing to models in the other app t
As I've said before, I like this idea, and the opt-in thing is even better
and gets rid of a lot of the compatibility headaches I was worried about.
The review looks good overall - have left a couple of notes, only really
the one change I want to see (the operational dependency stuff).
A
s thread is the best place for
long-form discussion).
Discussion welcome! This is by no means a final proposal, just a first
draft.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To uns
are about it" and
"stable and publicly documented". The alternative is to change the DEP to
just say we're going to start putting release notes up for certain internal
APIs, and then somehow list the ones we will somewhere (probably on the API
stability page).
Andrew
On Sat, Dec
Hi Marcin,
If you're using an external tool to manage schemas of models, just set
managed=False on the models and Django will stop trying to change their
schemas (including stopping making migrations for them).
Andrew
On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak
wrote:
>
> Hel
n execute() function that does nothing; that
should accomplish what you want. Alternatively, you could wrap all
migration operations into the State side of SeparateDatabaseAndState, but
that's a bit cumbersome.
Andrew
On Tue, Dec 16, 2014 at 4:42 AM, Marcin Nowak
wrote:
>
> Hi Andrew,
d
switch to if you wanted this behaviour (and a mixin with the actual logic
or something similar so it's easy to incorporate into other test runners).
Andrew
On Wed, Dec 17, 2014 at 6:59 PM, wrote:
>
> At the risk of reviving an old topic, I wanted to add one significant
> point in favo
Hi Tim,
I can have a look, but I can't be certain about hitting any deadlines. I do
want to get that deprecation in, though...
Did you want it with a view to us being able to drop that in for tests
rather than making migrations for every test app, I presume?
Andrew
On Fri, Dec 19, 2014 at
create it
as it would error out.
I'd test variations of that to see if your patch still works; if not, we'll
need a workaround again.
Andrew
On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz wrote:
>
> On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>>
ke a database column as far as the model is concerned, but isn't
one in reality.
Regards,
Andrew Ingram
On 22 December 2014 at 14:50, Collin Anderson wrote:
> Ditto. I'm ok with a tiny shim for GFK, and we should get the API right
> for RelatedObject going forward, (as long as
ch that more
as "migrations made and run at runtime as a special case" rather than
"syncdb".
If nothing else, I'd like to see the end-developer-facing parts, like the
syncdb command itself, gone.
Andrew
On Sun, Jan 18, 2015 at 1:43 PM, Claude Paroz wrote:
> Tim recently did
own schema just don't
run migrate. Is there something else that's not working right, or is that
being made too optimistically?
Andrew
On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel wrote:
> From Andrew: "The only extra thing it would achieve is not having Django
> record migra
Aha! Then, I would suggest redesigning MigrationRecorder to only make the
table when an actual recording operation is done, and have it swallow the
table not existing as "no migrations applied" the rest of the time, if
people think that seems sensible.
Andrew
On Thu, Jan 22, 2015 a
For what it's worth, I prefer one import per line, if only because it makes
diffs that involve changes to imports a lot easier to digest, and usually
smaller.
ie, something like this:
https://gist.github.com/AndrewIngram/16da35699bd495f79adb
Andy
On 30 January 2015 at 09:36, aRkadeFR wrote:
|
|-----|||
| text| none | text |
| safe| none | safe |
| text| text | text |
| safe| text | text | <-- this in particular makes me wonder
| text| safe | text |
| safe| safe | safe |
If this is what we want, what next step should I
Indeed, Django can make many migrations for an initial set if it needs them
to de-circularise dependencies (e.g. two models with foreign keys pointing
at each other - it splits one of their FKs into a second migration).
Andrew
On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney
wrote:
> Could
have pyc files turned off
in dev to stop this.
Andrew
On 11 Feb 2015 21:05, "abhillman" wrote:
> I have gotten bitten by lingering bytecode in migrations on several
> occasions. Steps to reproduce are a little bit complex, but here is an
> rough example:
>
> Loca
g difference
to most routers but it will stop lookups failing for models that have since
been deleted, for example)
Andrew
On Tue, Feb 17, 2015 at 12:58 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 17 févr. 2015, at 11:06, Loïc Bistuer wrote:
>
> > Th
all
>>
>> my_app_config.get_models()
>>
>> and I get a list of all of my models, but *my_app_config.models_module*
>> remains *None*
>>
>> If I try this from the django shell:
>>
>> from django.apps import apps
>> apps.get_app_config('my_app
this sort of thing as a
third-party command/backport if we wanted to have it usable on 1.8 and even
1.7 (the 1.8 feature set is frozen now, or I'd suggest quickly squeezing it
in).
Andrew
On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> O
different ways, kind of like makemigrations + sqlmigrate but without the
middle step of saving migrations to disk)
Andrew
On Mon, Mar 30, 2015 at 1:57 PM, Pascal Chambon
wrote:
> Thanks for your answers,
>
> l'm confused nonetheless, because their are two notions mixing up, here
use
migrations directly (as they were intended).
Andrew
On Tue, Mar 31, 2015 at 12:20 AM, Joachim Jablon
wrote:
> Not sure about this but wouldn't "RunPython" actually keep you from
> getting an proven accurate result ? Even if we could imagine running the
> migration in a
gging migrations
> issues, and with the appropriate documentation notes about RunSQL etc, I
> think it would be a useful addition.
>
This is in fact what I was suggesting when I said "tie the autodetector
into the SQL writer directly in-memory". It would do 99% of what people
want
I'm noting for posterity of this thread that I've opened a ticket and issued a
pull-request.
Ticket: https://code.djangoproject.com/ticket/24639
PR: https://github.com/django/django/pull/4497
--
You received this message because you are subscribed to the Google Groups
"Django developers
2 hard things
in computer science: cache invalidation. So, I wanted to get y'alls
opinions on whether this was worth attempting.
cheers,
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group
about the --keepdb option in Django 1.8:
> https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---keepdb
>
>
> On Friday, April 17, 2015 at 6:04:00 PM UTC-4, Andrew Farrell wrote:
>>
>> Hi Folks,
>>
>> I've been working on speeding up a
does (plus some concurrency issues with
default functions can be solved by moving them to the DB layer).
Andrew
On Sun, Apr 26, 2015 at 1:09 PM, Sam Baron wrote:
> Greetings, I know this is an old thread, but it's an issue I am coming up
> against and hopefully I can restart the conv
ot there in addition to syncdb/Creation classes, they
replaced them with cleaner, more featureful code.
Andrew
On Mon, Apr 27, 2015 at 1:33 AM, Marcin Nowak
wrote:
> Hi.
>
> Before v1.7 there were no migrations and Django was quite useful (for
> example with South as an 3rd party a
underlying problem, but not
the bug as described (e.g. for 14051, it would stop refs being pushed in
for uncommitted transactions). Still fine IMO, and definitely leave
comments on them noting this if it does land.
Andrew
On Mon, Apr 27, 2015 at 10:23 PM, Aymeric Augustin <
aymeric.augus...@po
Hi Tom,
When you say "testing migrations", what do you mean exactly? The migration
framework itself is heavily unit-tested, so I presume you intend to test
things like custom RunPython function bodies and the like?
Andrew
On Thu, May 7, 2015 at 3:30 AM, Tom Linford wrote:
>
ly faking these migrations? Or having Django do it for you
and getting it wrong?
Andrew
On Wed, May 13, 2015 at 10:27 AM, Markus Holtermann <
i...@markusholtermann.eu> wrote:
> Hi Steve,
>
> apart from what Tim said, since you commit the migration files as part
> of the apps' co
logs?)
Andrew
On Wed, May 13, 2015 at 2:05 PM, Shai Berger wrote:
> I think we had this discussion, more-or-less, around South migrations (I
> looked a little, but couldn't find it). The context there was, as Tim
> hinted,
> "forensics" -- trying to figure out how a syste
sure we should just lump a certain pattern of
socket worker in core straight away.
Andrew
On Mon, Jun 1, 2015 at 12:42 AM, Curtis Maloney
wrote:
> I think the real questions are:
>
> 1. What is stopping a 3rd party product from providing the features you
> want?
>
> If there is so
vertheless, it seems to prove the idea and is
also the way we can handle test database setup potentially, too.
On Mon, Jun 1, 2015 at 1:41 PM, Tim Graham wrote:
> As far as justification for dropping the old commands:
>
> 1. Andrew said earlier in the thread, "the sqlmigrate com
start proving it's possible, and then present that,
because in my experience having code examples can really make a proposal a
lot easier to understand. Of course, I'm also fully prepared for people to
shoot down my ideas - being a core team member doesn't give me some magical
ability
Based on my own experiences building isomorphic JavaScript apps with
Django, I haven't had any issues where I felt Django was getting in my way.
I've tackled the problem in two different ways, both of which worked
without any great difficulty:
1. The primary web-app is actually a node process. Eve
rything that's annoyed me
about web dev for the last 10 years. But Django has an excellent data
layer, and I want to keep using it if I can.
Andy
On 2 June 2015 at 18:17, Emil Stenström wrote:
> On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote:
>>
>> Based on my o
e it run
before the main PK change).
Andrew
On Wed, Jun 10, 2015 at 3:50 AM, Loïc Bistuer
wrote:
> I think we can link https://code.djangoproject.com/ticket/56 to
> https://code.djangoproject.com/ticket/14286.
>
> The problem is not so much how to create an UnsignedAutoField or a
>
responsive! And my example might crash, it's only running the websocket
server in screen!)
Andrew
--
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 r
will just fail.
Andrew
On Tue, Jun 16, 2015 at 12:48 AM, BearXu wrote:
> Personally I don't agree with implementing the Channel using in-memory
> mode first. Writing code to communicate among sockets will become very
> difficult for me(ordinary developer). If we see async in Dj
erhaps we could suggest that people prefix them with
their app name). I think enforcing separation beyond this isn't sensible if
the behaviour is going to be exactly the same anyway.
Andrew
On Thu, Jun 18, 2015 at 12:47 PM, BearXu wrote:
> It might be a better idea to set the task-pool
ames of those apps on the
makemigrations command line? Are you using something like --noinput?
Andrew
On Wed, Jul 15, 2015 at 3:16 PM, Marcin Nowak
wrote:
> Hello,
>
> I'm working on a project which is based on Django`s internal migrations.
> Sometimes when switching be
ternal app already has a migrations directory, so the
app in question should probably try and present a consistent choices 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 Nowa
est we can.
As for a short-term fix, Collin's idea of importing the choices into the
migration to stop it detecting more changes sounds like a decent temporary
fix.
Andrew
On Wed, Jul 15, 2015 at 4:46 PM, Marcin Nowak
wrote:
> Thanks for clarification, Andrew. I understand it.
>
>
x27;d rather we work towards something where fields could just say
"choices/label/etc. don't matter" and ship default ignores with all the
core fields.
Andrew
On Wed, Jul 15, 2015 at 5:03 PM, Tim Graham wrote:
> Andrew, do you think having the autodetector not "resolve&q
If we're going to introduce another setting, which I'm not super-keen on,
then let's made it exclusionary, something like MIGRATION_UNMANAGED_APPS.
Or, we could do something with the existing MIGRATION_MODULES setting, but
migrate needs that too so it might be confusing things.
f the app to override by
> supplying an AppConfig which will generate migrations (should they, for
> some use-case reason, want that).
>
Now this I like.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)&
would just blow up if you
tried to pass a function.
Andrew
On Wed, Jul 29, 2015 at 4:50 PM, Michael Manfre wrote:
>
>
> On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron > wrote:
>
>> Hi Loic,
>>
>> Agree with having a db_default kwarg.
>>
>> I am not
speed before it goes
forward.
Alternately, we could modify the autodetector to have a "create only" mode
that's more efficient or just write a new generator that is quick because
it knows it's only making nonmigrated apps' migrations.
Andrew
On Thu, Aug 6, 2015 at 4:56 PM,
app_a.0003, and then they ship a new version that has app_a.0004, then
suddenly app_a.0003 has two different children and the migration solver is
going to really hate you.
Do you have a proposed workflow or tooling that would get around this?
Andrew
On Mon, Aug 24, 2015 at 10:54 AM, Emmanuelle
t encourage extension with models, etc. I still think Django should make
it quite hard to do this and screamingly obvious that you're going down a
dark path, but at the same time we should at least have it be possible.
Andrew
--
You received this message because you are subscribed to th
pseudo-unmanaged, but I see no reason not to have the syncdb-like
solution keep working as it at least runs off of SchemaEditor now.
Andrew
On Thu, Aug 27, 2015 at 5:14 PM, Markus Holtermann wrote:
> The general benefit of *not* having migrations is the incredible better
> performance to set
ation Operation classes that people
could put into their migrations manually, or potentially have some other
way of outputting those migration files with operations in them (a lot of
the code to write them out is re-useable). Hopefully someone else has a
better idea!
Andrew
On Thu, Aug 27, 2015 at
think you want to take a stab at it,
you're more than welcome, and I'm more than happy to review patches against
migrations.
Andrew
On Thu, Aug 27, 2015 at 9:25 PM, Gavin Wahl wrote:
> That's too bad. I don't think it's really worth it unless the experience
> wor
idea, but I'm not sure if it was
similar or not. It definitely sounds faster - this is how South did it, of
course, and given we now have all the serialisation/deserialisation code
for models it would seem to be not too hard to do.
Andrew
--
You received this message because you are subsc
g a
> check-constraints feature in Django (I'm certainly in favor).
>
For the record, I am also in favour of this.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscri
I'm on board merging this without Oracle support - if I understand right,
it means we just have to run those non-parallel for now, so we're not
losing anything, right?
Andrew
On Sun, Aug 30, 2015 at 1:19 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> He
101 - 200 of 630 matches
Mail list logo
