I agree we can just say that initial_data can be used as a fixture for
tests rather than being auto-loaded - and we could perhaps even put it in
the base testcase so it always auto-applied somehow - but that doesn't get
over the fact that you can't rely on data migrations to set up your
database fo
2014-04-19 14:15 GMT+02:00 Anssi Kääriäinen :
> On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote:
>
> Getting dump-and-reload support for 1.7 seems hard, so from the above
>> options this leaves just 2) - not deprecating initial_data yet. Or we
>> need to find some other solution not listed above.
Hi Marc.
Thanks for you explanation.
2014-04-19 13:46 GMT+02:00 Marc Tamlyn :
> Hi Andrey,
>
> There are limited use cases where initial data is a good idea. Examples
> might be where you have a list of countries for relating to or some other
> fixed set of data.
>
> The idea is that now instea
On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote:
Getting dump-and-reload support for 1.7 seems hard, so from the above
options this leaves just 2) - not deprecating initial_data yet. Or we
need to find some other solution not listed above.
Hmmh, there is actually a pretty straightforward upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Trey, all,
I know we shortly talked about that at PyCon but I forgot to mention
that a while ago we took a stab at that already. Sean Bleier was spear
heading it and I helped out here and there:
https://github.com/sebleier/django/compare/4f3ad28a9b
Hi Andrey,
There are limited use cases where initial data is a good idea. Examples
might be where you have a list of countries for relating to or some other
fixed set of data.
The idea is that now instead if having a hard to maintain fixture for that
table, you populate it with a data migration i
Hi Christian.
But, as far as I know, data migrations are "some logic" for translate data
from old scheme to new scheme and initial_data are files for load intial
data. I do not see where they could serve for the same purpose. Is really
confusing.
Personally, putting initial data of my application
hm, at first i didn't even read the release notes..
But i think we should definitly make a blocker issue in trac.
Currently re-introduce initial_data is the worst thing we could do, since
django 1.9 requires migrations and do deprecate that behavior:
> Deprecated since version 1.7: If an applicati
Hi!
At this time I haven't touched the new migrations system for django. But
now, reading the releases notes and this thread...
I don't understand how data migrations can replace initial_data, are two
things completely different and they have completely different scope. I'm
slightly confusing.
In
On 04/18/2014 07:41 PM, Andrew Godwin wrote:
Ah yes, flushing, I forgot we did that for lesser DBs.
I can think of several solutions:
- Run the entire migration set every time you flush the database.
This is, obviously, not practicable.
- Re-introduce initial_data fixtures; I'd rather not, as
It seems bit-related fields are not on the list (
https://www.kickstarter.com/projects/mjtamlyn/improved-postgresql-support-in-django
)
I think integer fields should be used as base field instead of bit fields,
just like disqus's one.
Reasons:
1. Supports all databases django supported.
2. Bette
11 matches
Mail list logo
