Problems with DatabaseCreation, table names, and index names

Hi all, I'm posting this here, not as a ticket, as I'm not entirely sure it's Django's problem, and so would like some input*. [Base]DatabaseCreation has a method sql_indexes_for_field, which, handily, returns the SQL indexes for a field. Less usefully, both PostgreSQL and MySQL have limits

Re: Problems with DatabaseCreation, table names, and index names

On 11/03/10 01:05, Russell Keith-Magee wrote: We have an incentive to fix it too -- #12977 points out that Django's own test suite runs foul of this problem. Ah, that's not good. Just documenting the problem isn't really a solution, IMHO. MySQL is the fly in the ointment here, because it

Re: GSoC: Data importation class

I feel the need to wade in here, since this is vaguely my area. On 25/03/10 17:47, subs...@gmail.com wrote: The last bit sounds a bit nebulous. You could optimise it by not including any empty files, or be a bit more specific about what the empty files are meant to represent. :) startapp,

Re: Opinions sought on m2m signal ordering

On 27/03/10 17:08, Russell Keith-Magee wrote: There are 5 options I can see. Option 1: Do nothing. #13087 describes a use case we don't want to support, so we ignore it. I think it should be supported; it seems like a reasonable suggestion, and I can see reasons for implementing things th

Re: Opinions sought on m2m signal ordering

On 28/03/10 00:01, Russell Keith-Magee wrote: Cache invalidation is a reasonably compelling case for pre-signals; if you invalidate a cache on the post-signal, there is a small window between having modified the m2m and the cache being flushed. In that window, any operation hitting the cache will

Proposal: Schema migration/evolution backend

Hi all, As perhaps was inevitable, I'm proposing implementing part of a schema migration backend in Django. I'm not sure if this is a 1.3 thing (it may well be 1.4, perhaps with some implemented in time for 1.3 but not exposed), but it's something I'd like to get started in this release cycle

Re: Proposal: Schema migration/evolution backend

On 28/05/10 13:06, Andrew Godwin wrote: Hi all, As perhaps was inevitable, I'm proposing implementing part of a schema migration backend in Django. I'm not sure if this is a 1.3 thing (it may well be 1.4, perhaps with some implemented in time for 1.3 but not exposed), but it'

Re: Decision required: PostgreSQL minimum versions

On 09/06/2010 12:59, Russell Keith-Magee wrote: Hi all, While we support PostgreSQL, our documentation doesn't actually specify a minimum supported version. We have a couple of features that are no-ops for versions prior to 8.2 (savepoints and database autocommit), but we don't actually document

Imports in the tutorial

Hi all, I noticed today that the tutorial still does imports like "from mysite.polls.models import Poll", and URLs like "(r'^polls/$', 'mysite.polls.views.index')". At least in the places and projects I've worked with, the standard has been not to use the project name as part of the import,

Re: Imports in the tutorial

On 11/06/2010 03:28, Peter Baumgartner wrote: In my experience, almost every project has domain-specific applications that don't get reused. If you have a reusable app, you bundle it separately (like South). I entirely agree, but there's also a lot of domain-specific apps people make tha

Re: Imports in the tutorial

On 11/06/10 17:00, Peter Baumgartner wrote: > Why do your two sites need to share the same python path? Virtualenv > solves this problem quite gracefully. > They don't have to, but bear in mind that: a) The tutorial is aimed at people new to Django, and often new to Python. Virtualenv isn't e

Re: Imports in the tutorial

On 11/06/2010 17:38, Russell Keith-Magee wrote: You're not missing anything specific -- it's really just a matter of time. Good documentation take time to write; doubly so for good tutorials. The issue you raise - that the current tutorial is exclusively "app inside project" has been raised as

Re: Imports in the tutorial

On 12/06/2010 01:03, Russell Keith-Magee wrote: What - very very quickly? I don't see the problem :-) Well, that wasn't quite the quality I was going for, but you never know. Problem is there's several things that could go in a part 5 (in addition to all of those there currently), like

Re: Imports in the tutorial

On 15/06/2010 20:52, Brian Luft wrote: Short of new tutorials, I think the best service we could do for the (beginner) community is to at least call out a sidebar that provides some brief context around whether or not to namespace by project. Since this is a matter of personal preference the res

Changing the role of the Technical Board

Hi everyone, I want to start a conversation about the Technical Board and its role in Django, and how I'd like to change it, including its name. Since its inception, the Technical Board has effectively only functioned as a backstop vote for large features that require DEPs, of which there have

Re: Changing the role of the Technical Board

These are some great points, James - let me try to tackle them roughly in order. Proposing features - this is already in DEP 10, so I more just want to get that aspect of the Board actually going (and, as a side-effect, have something to aid fundraising). I am talking with the current Board sepa

Re: Changing the role of the Technical Board

my evolving belief in the need for visible, servant leaders in OSS communities rather than trying to embrace a flat hierarchy with mechanical checks and balances - but that is for another day. Andrew On Mon, Oct 24, 2022, at 4:26 PM, James Bennett wrote: > On Mon, Oct 24, 2022 at

Re: Changing the role of the Technical Board

On Tue, Oct 25, 2022, at 12:12 AM, James Bennett wrote: > > My first reaction to this is: if having a DEP that says the Technical Board > is supposed to take the lead in gathering feature proposals didn't get them > to do it, it doesn't feel like another DEP saying they're responsible for > t

Re: Changing the role of the Technical Board

I agree the Technical Board has not followed the letter of DEP 10, and I think the things you have highlighted are all valid failings, but I want to focus on - what should we do to remedy them? Given the lack of candidates we already have, if we ditch the current Board and try to elect a new on

Re: Changing the role of the Technical Board

DEP shortly so it's more clear exactly what I want to change at a written-rules level - I suspect feedback on a more concrete proposal will help us talk about it more clearly. Andrew On Wed, Oct 26, 2022, at 4:55 PM, James Bennett wrote: > On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwi

Draft Steering Council DEP

Hi all, As a followup to my previous post about potential changes to the Technical Board - for which I thank you all for the feedback - I have taken the process to the next step and written a draft DEP: https://github.com/django/deps/pull/75/files (If you wish to see the DEP with styling, it c

Re: Proposal for Django Core Sprints

Hi Paolo, I do like the overall idea - a few thoughts below. My first concern for this, which somewhat echoes James, is that trying to organise an additional in-person event that a large number of contributors are expected to go to is difficult. Funding considerations are one concern - we woul

Re: Draft Steering Council DEP

On Sun, Oct 30, 2022, at 10:42 PM, James Bennett wrote: > On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin wrote: >> __ >> >> I have copied in the DSF Members mailing list as it is a governance-related >> DEP, but if we could keep all discussion on the thread in the Dj

Re: Draft Steering Council DEP

On Tue, Nov 1, 2022, at 6:54 AM, C. Kirby wrote: > Having run the elections for the current technical board I agree with > Andrew's assessment that a more open requirement to run is a good idea. It > may create a bit more work on candidate verification for the DSF Board and > Fellows, but anyt

Re: Proposal: Clarify individual members page

Just want to pop in and say these are great ideas - feel free to copy me in on any PR if you want extra opinions! On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote: > Great, Thanks Andrew. No urgency 😊 > > On Tue, 8 Nov 2022 at 16:16, Andrew Mshar wrote: > >> Will do, Carlto

Technical Board vote on DEP 0012: The Steering Council

Hi all, As it seems discussion on DEP 12 has reached its end, and we received generally positive feedback, I am requesting a vote from the technical board on the following: "Shall we accept DEP 12 and send it to the DSF Board for further approval?" Note that as this is a governance change, it

Re: Technical Board vote on DEP 0012: The Steering Council

Yes, I agree we can use the forum in future since it's less tied to Google. Provided the current +5 vote carries through to the end of the voting period, I will be suggesting that the Technical Board triggers the DEP 10 mechanism where we move this to the membership for a vote once the DSF Board

Re: Technical Board vote on DEP 0012: The Steering Council

concluded and a result reached. Andrew On Wed, Nov 30, 2022, at 10:44 AM, Andrew Godwin wrote: > Yes, I agree we can use the forum in future since it's less tied to Google. > > Provided the current +5 vote carries through to the end of the voting period, > I will be suggesting that th

Re: Can we move the activity on this list to the Forum now?

I did some investigation of moving django-users and django-developers to the Forum right after DjangoCon; I wanted to see if we could import all the old posts too, which we probably could, but I'm not entirely sure of the utility of that. I will say that the forum is a lot easier to moderate -

DEP 12 (Steering Council) Fully Adopted

Hi everyone, I am pleased to report that we've completed the extended approval process for DEP 12, which was needed since it was a governance change. Both the Technical Board and the DSF Board voted to not require a vote from the membership on the change, so it is now officially adopted and I w

Re: Can we move the activity on this list to the Forum now?

... > > On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers > (Contributions to Django itself) wrote: >> Hi all, >> >> I find that the signal-to-noise ratio on this mailing list is (by my >> determination) quite bad around this time of ye

GSOC 2012

Hello everyone, As some of you have already noticed, we've been accepted into GSOC 2012 and we're now starting to discuss ideas with students. The actual application period doesn't open until the 26th March, but we'd encourage you to start discussing applications on this mailing list before th

Re: [GSoC 2012] Schema Alteration API proposal

On 19/03/12 11:08, Jonathan French wrote: On 18 March 2012 23:33, Russell Keith-Magee mailto:russ...@keith-magee.com>> wrote: > 2. An inspection tool that generates the appropriate python code after >inspecting models and current state of database. The current consensus is

Re: Schema Alteration API proposal

On 19/03/12 20:33, Kushagra Sinha wrote: Andrew's thread[1] also mentions - "backends will always be able to generate SQL for operations, but it won't necessarily be runnable (things like index names can only be resolved at runtime, so you'd get code like "DROP INDEX <> ON users;"." [1] https:/

Re: Improved Error Reporting in Django - GSoC

On 19/03/12 18:12, Sachin Gupta wrote: Hi, My name is Sachin Gupta and I am student of Indian Institute of Technology Roorkee, in my final year of undergraduate course in Computer Science. I have been developing a project entirely based on Django for the last 4 months. Here is the link

Re: Improved Error Reporting in Django - GSoC

On 20/03/12 07:18, Sachin Gupta wrote: Could you guide me what number of error fixes would be good work for GSOC proposal. Also if there are any class of Django errors that are of greater concern (like django.db) There's no clearly defined "number" that would be good - we'll be looking at you

Re: Schema Alteration API proposal

On 21/03/12 13:27, Kushagra Sinha wrote: One more thing: The current creation API in django has methods like "sql_create_model" which basically return sql and it is the caller's responsibility to either call cursor.execute on it (syncdb) or output the sql itself (sql). South's (and xtrqt's) desi

Re: Improved Error Reporting in Django - GSoC

On 20/03/12 20:33, Sachin Gupta wrote: It seems most of the errors on this page https://code.djangoproject.com/wiki/BetterErrorMessages are very old. It states that if the attribute enctype="multitype/form-data" is not sent then the following error comes up TypeError at ... string indices must b

[GSOC Announce] Student application period open

Just a quick note to everyone to say that the student application period for GSOC is now open, and closes on Friday, 6th April. As I've mentioned on this list previously, please discuss your applications with us first so we can give you some feedback rather than just submitting them directly -

[GSOC Announce] One day remaining for applications

Hi everyone, Just a quick reminder that there's only one day left for GSOC applications - the deadline that they must be filed on the GSOC website by is April 6th, 19:00 UTC (roughly 30 hours from now). Andrew -- You received this message because you are subscribed to the Google Groups "Djan

Re: [GSoC 2012] Schema Alteration API proposal

Just thought I'd chime in now I've had a chance to look over the current proposal (I looked at the current one you have in the GSOC system): - When you describe feeding things in from local_fields, are you referring to that being the method by which you're planning to implement things like sy

Re: [GSoC 2012] Schema Alteration API proposal

On 06/04/12 06:34, j4nu5 wrote: Actually I am not planning to mess with syncdb and other management commands. I will only refactor django.db.backends creation functions like sql_create_model etc. to use the new API. Behaviour and functionality will be the same after refactor, so management comman

GSOC 2012 Projects

Hi everyone, I'm pleased to announce that Django has accepted two proposals for this year's Google Summer of Code: Customizable serialization, from Piotr Grabowski http://www.google-melange.com/gsoc/project/google/gsoc2012/grap/15001 Security Enhancements, from Rohan Jain http://www.google-me

Proposed Field API additions

Hi everyone, As part of my planning for adding schema alteration/migrations into Django proper, I need to make a few changes to Fields to allow for better serialisation of model definitions (pretty much a requirement for any change-detecting migrations system). In particular, I propose: - Requi

Re: Proposed Field API additions

On 07/06/12 20:14, Alex Gaynor wrote: > > > On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin <mailto:and...@aeracode.org>> wrote: > > > In particular, I propose: > > - Requiring that all fields expose a method which says how to > reconstruct them.

Re: Proposed Field API additions

On 07/06/12 21:56, Anssi Kääriäinen wrote: > Is the reason for this to be able to track changes to field by > checking if its init arguments have changed? Why is it not possible to > track changes by checking the SQL output the field will generate > instead? This is guaranteed to be a string, and s

Re: Proposed Field API additions

On 08/06/12 18:16, Michael Manfre wrote: > > > On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote: > > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor up

Re: Proposed Field API additions

On 08/06/12 16:16, Anssi Kääriäinen wrote: > I did a little digging into South code, and I think I now understand > the needs. Basically, when you migrate a model, you might need to read > the database data by using the old model definitions. You can't use > the currently installed model definition

Re: Proposed Field API additions

On 08/06/12 16:45, Jacob Kaplan-Moss wrote: > Hi Andrew -- > > Generally I'm +1, and I think I see the point pretty clearly. Just a > couple of questions: > > On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin wrote: >> - Requiring that all fields expose a method whi

Re: Proposed Field API additions

On 08/06/12 17:42, Carl Meyer wrote: > Hi Andrew, > > On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and key

Re: Proposed Field API additions

On 08/06/12 20:01, Anssi Kääriäinen wrote: > On 8 kesä, 19:42, Carl Meyer wrote: >> Yuck. I am not at all convinced that this cure isn't worth than the >> disease. In every case where Django has introduced flattened >> pseudo-namespaces in place of Python's existing namespace system, I think >> it

Re: Proposed Field API additions

On 10/06/12 21:54, Anssi Kääriäinen wrote: > I agree the needed_fields.py idea was bad. One part of the idea was > that you would get immediately broken migrations if you remove a > field. Do all the migrations break if you have a broken field > reference, or only when you actually use a migration

Re: Proposed Field API additions

On 11/06/12 10:27, Anssi Kääriäinen wrote: > All of the above sounds good - my main worry was that if you subclass > a field, then it will not get a rule match as the module path prefix > will be different than the parent field's. I don't know if this is an > issue even in South... But if the rule

Re: QuerySet refactoring

On 13/06/12 17:15, Luke Plant wrote: > I think this is a very necessary piece of work. The problem with that > layer of code is that it is very difficult to really grok and therefore > to review patches. It would take almost as much effort to do a review of > a substantial patch as the patch itsel

Re: Test runner with search

On 14/06/12 11:51, Anssi Kääriäinen wrote: > On 14 kesä, 13:35, Chris Wilson wrote: >> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I >> got tired of having to remember my test class names and of typing so much: >> >> ./manage.py test binder.BinderTest.test_can_create_u

Re: auth_permission column lengths

On 19/06/12 15:25, Stephan Jaensch wrote: > Hi Florian, > > Am 19.06.2012 um 16:12 schrieb Florian Apolloner: > >> Django itself can't change that currently since there is no >> support for schema alteration in Core. Once we get that we can >> tackle issues like that and increase to a sensible li

Re: auth_permission column lengths

On 19/06/12 16:13, Greg Aker wrote: > Florian: > > I don't think waiting for migrations in the Django core is totally > necessary to fix a bug like this (or others that might be similar). > With proper documentation in the release/upgrade notes, I think it's > completely reasonable to expect some

Re: Plans for "forms"

On 21/06/12 11:58, Klaas van Schelven wrote: Hi all, I'm not entirely sure about the forum to ask this question: the motivation is "django-users" like; but since it's about a roadmap / the future I suppose only developers will know the answer. I vaguely remember there being mention of big plans

Re: Proposal: use SQLAlchemy Core for query generation

On 30/06/12 15:22, Luke Plant wrote: > Hi all, > > A good while back I put forward the idea of using SQLAlchemy Core in > Django [1]. Having had more experience working with SQLAlchemy, I'm > putting that idea forward as a formal proposal, as I mentioned in a more > recent thread here. > > Apolog

Re: Proposal: use SQLAlchemy Core for query generation

> I am pretty sure SQLAlchemy-Migrate has fallen out of favor. You should > check Alembic, http://alembic.readthedocs.org/en/latest/. Ah, interesting. Alembic doesn't appear to support fully mutating SQLite databases, which is the really gnarly part of the South code I'd love to outsource. Looks

Re: Django should load custom SQL when testing

On 26/07/12 19:33, Anssi Kääriäinen wrote: On 26 heinä, 19:35, Andrei Antoukh wrote: Having the hooks as a method or function, I find it much more interesting than having them in files. Above that allows logic in these methods, which with flat files is not possible. I also like raw SQL in Pyth

Re: GSoC Check-in: Security Enhancements

Thanks for your work during the GSOC, Rohan - don't worry about not achieving everything, it looks like there's still some useful code there! Hopefully we can get some of the code merged, especially centralised tokenisation if it's so near completion, as it looks like a nice bit of cleanup code!

Re: Backporting some Python 3 support features to 1.4.x?

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, 2012 at 3:05

Re: Testing multidb with TEST_MIRROR

That's an incredible speedup - I've had a quick look over the patch, and it looks to be doing all the right things, so I'd definitely be behind merging this in. Have you tried running the test runner over some third-party apps' tests to make sure it works? I suspect South's/migrations' might get we

Schema Alteration - Review needed!

Hi all, I have now, I believe, got a working, feature-complete schema alteration branch ready to go. It has full support for PostgreSQL, MySQL, and SQLite, and follows the rough design principles I emailed the list about a while back. It's fully tested, but no documentation yet - I'm not sure wha

Re: Schema Alteration - Review needed!

> > > 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 email to django-developers@goo

Re: Schema Alteration - Review needed!

An update from discussions with Alex and Anssi - I'm going to modify things a little so we don't have a Borg-pattern AppCache (i.e. you can instantiate it multiple times and get different caches), which should solve most of the problems currently caused by app cache state fiddling. Should take a da

Re: Schema Alteration - Review needed!

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

Schema Alteration update

So, the patch [1] is looking alright, but after some consideration I think it's going to be best to leave this until just after the 1.5 branch has happened and then merge it in as part of the 1.6 cycle. My reasoning is thus: - The whole point of getting something into 1.5 was so I could build mi

Re: Schema Alteration update

Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps not loudly enough - Jacob and I had a talk at DjangoCon EU where he said he wanted it all in core, and I tend to agree. Preston has had a look at what I'm doing/planning with AppCache and apparently it'll be compatable with wh

Re: Schema Alteration update

11, 2012 at 11:21 AM, Luke Plant wrote: > On 28/09/12 08:41, Andrew Godwin wrote: > > Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps > > not loudly enough - Jacob and I had a talk at DjangoCon EU where he said > > he wanted it all in core, and I te

GSoC 2013 - New and improved!

I'm very pleased to announce that Django is part of Google Summer of Code once again - and that this year, we're widening the scope of the kinds of projects we'll be accepting. In past years, we've only accepted projects working on Django itself, and while this has resulted in some very useful pie

Re: [GSoC 2013] Improved error reporting

Hi Damian, We don't generally accept GSOC projects that are just a bit grab bag of problems - this is looking a little bit like that. I'd like to see a better breakdown of what kind of time each ticket would take and what your planning schedule would be - in particular, I'd like to make sure you h

Re: [GSoC 2013] Composite fields: first draft of the proposal

Hi Michal, This looks like a good starting point for a proposal (not to mention that we don't doubt that you know about the problem area here!) - a few comments: - I'd like a bit more detail on some of your timeline points, in particular what the introspection parts and primary key updates are (

GSOC: Deadline soon!

Hi everyone, It's great to see all the GSOC proposals on the list and the feedback being useful, but I feel I should remind you all that the deadline is this Friday, May 3rd, at 7pm UTC (so 11am if you're on the west coast of the US, for example). Melange, the GSOC software, can be a little hard

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

I feel like the deployment problem is one that cannot be solved in a mere 12 weeks and I'm not sure django-deployer is the right approach to encourage for this - it sits at the wrong level of abstraction and looks pretty fragile, and I'd be hesitant to put any sort of official emphasis on it withou

Re: Django 1.6 release timeline

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, 2013 at 4:45 PM

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

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

Re: test discovery

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.com> wrote: > > On T

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

gt; model containing a ForeignKey or indexed field, then re-creating the model. > (All via db migrations) > > The instinctive desire is to rename indexes when renaming objects whose > name was used in the index creation. But speaking to Andrew Godwin, he > feels this would be quite a larg

Re: Infinite loop in migration code

Hi Luke, That was already a fix for infinite looping on the previous iteration that I committed at the DUTH sprints, but your fix looks more understandable and cleaner, so I say commit it for sure. As for backporting - I think we should, as this is potentially a crash bug (though not a data loss

Re: Adding model managers to migrations

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). Andrew On

Experimental APIs DEP

Hi everyone, One of the results of discussions at Django Under The Hood was support for the idea of marking APIs "experimental" - that is, document them and include them in mainline Django releases, but away from the standard Django deprecation cycle while still not hiding them under the "Internal

Re: Experimental APIs DEP

My notes from the meeting say "experimental API language", so I may have taken an adjective too literally when I made this. Nevertheless, the key thing _I_ want to see is for us to commit to putting release notes out for some of Django's APIs that aren't necessarily considered stable. The 1.7 data

Re: Bypassing 1.7+ migrations

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

Re: Bypassing 1.7+ migrations

sible via some setting. > That's why I wrote to developers forum directly. > Please think about that. > > Marcin > > On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote: >> >> Hi Marcin, >> >> If you're using an external tool to mana

Re: Migrations in Django 1.7 make unit testing models harder

I agree that migrations are slower than syncdb - that's perhaps the only thing worse about them - but the reason we plan to deprecate the other methods is code simplicity; migrations does not share almost any code with the old DatabaseCreation backends, and if we don't deprecate it we're going to e

Re: Migrations in Django 1.7 make unit testing models harder

to investigate this solution in the next month or so before > 1.8 alpha? I think we need a solution in 1.8 if we are to complete #22340 - > Legacy > Table Creation Methods Not Properly Deprecated (otherwise, we can again > postpone that deprecation). > > On Friday, December 19, 2014

Re: Migrations in Django 1.7 make unit testing models harder

Clause, I believe that line is to allow people to run makemigrations when AUTH_USER_MODEL points to an app that doesn't yet have migrations; before, it would fail hard, as the AUTH_USER_MODEL was not in the migrate state and so nothing could use it, and you couldn't run makemigrations to create it

Re: Keeping apps without migrations?

My main argument for removing them entirely was the dependency issues between apps with and without migrations. Having syncdb use SchemaEditor is a big step and one I'm happy we've got to, but the only advantage of keeping syncdb is for the test suite and I'd rather we approach that more as "migrat

Re: Must a Django Database Support Migrations?

ns the > "one obvious way to do it" and turning them off the not obvious way. > > Ivan > > On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote: >> >> My thoughts in brief on this: >> >> - Database backends don't support migra

Re: Must a Django Database Support Migrations?

ns and thus > creates the migration table. > > /Markus > > On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin wrote: >> >> Hi Ivan, >> >> I'm not sure what you're asking here - are you asking to have a way to >> not have Djan

Re: Possible bug: makemigrations caching prior migrations after deletion

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 you p

Re: Bytecode in Migrations

Your problem is likely that the pyc file for the new initial migration somehow seems newer than the py file and so Python is using it over the new source file. I'm not sure how this happens if it's a new migration, but I've seen it happening when switching git branches before. We have pyc files tu

Re: Signature of the allow_migrate database router.

I am fine with the proposed change to allow better routing of RunSQL/RunPython (though in the RunPython case people can easily do routing inside the python code provided anyway, as you can see the DB aliases there). Aymeric: The problem with your proposal is that there's no easy way to get the ver

Re: Fate of sql* management commands

I must also point out that the sqlmigrate command will still get you SQL from migrations, though it sadly lacks the ability to take a range of migrations, optimise them down, and output the SQL for _that_ - that's probably the best thing for us to aim towards, and will almost entirely recreate the

Re: Fate of sql* management commands

rations if necessary), or the handling of apps > that have no support for migrations. > > Sure, people encountering troubles might make like I did - start a brand > new project and mysqldump it after whole migration - but if we can expose > that information in a straightforward way, l

Re: Fate of sql* management commands

thon migration, who knows what the proper SQL would be ? > > (again, I may be missing a point there) > > -- > Joachim Jablon > > > Le lundi 30 mars 2015 06:00:10 UTC+2, Andrew Godwin a écrit : >> >> I must also point out that the sqlmigrate command will

Re: Fate of sql* management commands

> > > > > An alternative would be to ignore migrations files, regenerate a fresh > > set of migrations, and dump the corresponding SQL. > > I think this approach would be much preferable to using the totally > separate legacy code path. Presented as a tool for debugging migrations > issues, and wit

Re: Setting database default values in migrations (postgres)

curious if this would be an acceptable solution. > > Thanks, > Sam > > > On Saturday, November 1, 2014 at 10:17:50 AM UTC-7, Shai Berger wrote: >> >> On Friday 31 October 2014 19:16:15 Jon Dufresne wrote: >> > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin >>

  1   2   3   4   5   >