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 schem
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:
>
> Hello!
>
> I'm using
Hi Andrew,
Thanks for a reply. But as I've mentioned above I can't set managed=False
on models delivered from external apps like django.contrib.auth,
django.contrib.sessions, and many more. Forking them is not an option.
I think that bypassing migrations should be possible via some setting.
Th
Hi Marcin,
You can't bypass migrations as much as you can't bypass syncdb; that is,
the commands are separate and you can choose not to run them (or just
delete the migration files). As far as I can tell your only issue is the
runserver warning that you have unmigrated changes, which there's curre
Hey Marcin, Andrew,
setting manager=False wouldn't work either, as the migrations for those
models still need to exist. I probably have references to them which makes
them a requirement for FKs in migrations. Unmanaged models behave exactly
the same as managed models in migrations, with one exc
Hello all,
I just grabbed this ticket, but then I noticed in pull request #3735 that
we don't have a consensus as to whether this feature should be added. Since
I'm new around here, I'd like to ask everyone's opinion on whether we
should move forward on this. I can implement it within a few day
Hi Mike,
Thanks for grabbing it. I'd suggest to wait for the patch for #23983 being
merged and than work on the updated master branch. From my point of view,
the pull-request shouldn't add this new feature, as it would be backported
to 1.7 which isn't covered by the backporting guidelines. Thus
Hi everyone,
We're incredibly proud to share with you the new design of the Django website,
the documentation and the issue tracker.
This is a long time coming and we couldn't be happier to finally ship it :)
As you can imagine, there will be bugs, so please bear with us and report
issues to t
Looks great. Thanks.
Will this same look apply to the admin backend?
-bobby
> On Dec 16, 2014, at 11:09 AM, Jannis Leidel wrote:
>
> Hi everyone,
>
> We're incredibly proud to share with you the new design of the Django
> website, the documentation and the issue tracker.
>
> This is a lon
Looks great! Just surfing around website and it's changed. Cool! :D
среда, 17 декабря 2014 г., 0:09:55 UTC+8 пользователь Jannis Leidel написал:
>
> Hi everyone,
>
> We're incredibly proud to share with you the new design of the Django
> website, the documentation and the issue tracker.
>
> Thi
Thats a Fantastic feel
Ramesh
On Tue, Dec 16, 2014 at 9:47 PM, Bobby Mozumder wrote:
>
> Looks great. Thanks.
>
> Will this same look apply to the admin backend?
>
> -bobby
>
>
> > On Dec 16, 2014, at 11:09 AM, Jannis Leidel wrote:
> >
> > Hi everyone,
> >
> > We're incredibly proud to share w
It looks great. Awesome work, everyone involved!
Jannis/Russ -- y'all mentioned a style guide in the blog post, but I don't
see one in the docs. Is that available somewhere?
-T
---
Travis Swicegood
512-693-7051 | @tswicegood (most everywhere)
On Tue, Dec 16, 2014 at 8:32 AM, ramesh naidu
wrot
Awesome work
On Tue, Dec 16, 2014 at 10:45 AM, Travis Swicegood
wrote:
>
> It looks great. Awesome work, everyone involved!
>
> Jannis/Russ -- y'all mentioned a style guide in the blog post, but I don't
> see one in the docs. Is that available somewhere?
>
> -T
> ---
> Travis Swicegood
> 512-69
Really nice! Great job!
On Tue Dec 16 2014 at 5:56:41 PM Carlos Aguilar
wrote:
> Awesome work
>
> On Tue, Dec 16, 2014 at 10:45 AM, Travis Swicegood
> wrote:
>>
>> It looks great. Awesome work, everyone involved!
>>
>> Jannis/Russ -- y'all mentioned a style guide in the blog post, but I
>> don
> On 16 Dec 2014, at 17:45, Travis Swicegood wrote:
>
> It looks great. Awesome work, everyone involved!
>
> Jannis/Russ -- y'all mentioned a style guide in the blog post, but I don't
> see one in the docs. Is that available somewhere?
Yeah, it's semi-public right now since we don't have a
> On 16 Dec 2014, at 17:17, Bobby Mozumder wrote:
>
> Looks great. Thanks.
>
> Will this same look apply to the admin backend?
Very unlikely, this was about redesigning the public Django websites.
Jannis
>> On Dec 16, 2014, at 11:09 AM, Jannis Leidel wrote:
>>
>> Hi everyone,
>>
>> We're
Hallöchen!
Jannis Leidel writes:
> We're incredibly proud to share with you the new design of the
> Django website, the documentation and the issue tracker.
It's certainly beautiful but may I suggest to add contrast a bit?
For my laptop monitor / my eyes, e.g. "Note" boxes or source code
snippet
> On 16 Dec 2014, at 20:00, Torsten Bronger
> wrote:
>
> Hallöchen!
>
> Jannis Leidel writes:
>
>> We're incredibly proud to share with you the new design of the
>> Django website, the documentation and the issue tracker.
>
> It's certainly beautiful but may I suggest to add contrast a bit?
Somehow I hate it. The website is the worst website I've seen since a long
time.
The contrast is really aweful.
The issue Tracker got unusable due to the colors that aren't focused on
readability.
Overall it looks like a mess, just to have a new design.
Doesn't look like a designer or a graphic g
Hi Christian,
While I'm sure you didn't mean it this way, your email frankly makes you
sound like an jerk, and that tone is not appropriate for this list.
You've not substantiated any of your claims, other than that it your
personal preference.
If you'd like to make specific, *actionable* sugges
On Tuesday, 16 December 2014 18:23:29 UTC+11, Michał Modzelewski wrote:
>
> Sure. I was planning to work on it myself, but wanted to discuss API,
> passing in output_fields, and casting results first.
> I started with 2 classes because I only needed SimpleCase first to
> implement the bulk_update
Hi everyone,
First, there was ticket #10461[1] -- a complaint that annotate doesn't work
well with generic relations. Then, it was documented[2] as not working. But
then, people continued looking at the ticket, and in the end, it was declared
as fixed and a test was added[3]. But deeper checkin
Unlike in previous release cycles, we are going to try a complete feature
freeze at alpha. The details are outlined here:
https://code.djangoproject.com/wiki/Version1.8Roadmap
On Tuesday, December 16, 2014 8:01:23 PM UTC-5, Josh Smeaton wrote:
>
> On Tuesday, 16 December 2014 18:23:29 UTC+11, Mi
I admit I don't fully understand how generic relations work (I try not to
use them in my projects), but I would think we should be able to make
annotations work properly with them. Now that aggregates are based
internally on F() objects, we should be able to special case F() for
generic relatio
Thanks Tim, exactly what I was after. I linked to the wiki but obviously
didn't read it all :/
Michal, do you think you'll be able to pull Case expressions together by
the first or early second week of January to allow for review and changes?
Cheers
On Wednesday, 17 December 2014 12:28:53 UTC+
Will do, thanks. If we haven't gotten the go-ahead before the 22nd I'll
un-assign it before I go on vacation.
On Tuesday, December 16, 2014 6:58:08 AM UTC-7, Markus Holtermann wrote:
>
> Hi Mike,
>
> Thanks for grabbing it. I'd suggest to wait for the patch for #23983 being
> merged and than wor
On Wed, 2014-12-17 at 03:12 +0200, Shai Berger wrote:
>
> But deeper checking[4] finds that the
> annotation does not do the intuitive thing -- at least when aggregating over
> the related objects themselves (rather than fields on them), the field it
> uses
> to aggregate on is the relation fi
27 matches
Mail list logo