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
On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote:
>
> If you plan to continue using
> Django fields as type information (as South does), what potential issues
> do you see there?
>
The only issue I can think of is the case of custom fields created by the
user.
--
You received
On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote:
>
> 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
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
On 04/04/2012, at 11:50 PM, j4nu5 wrote:
> Hi Russell,
> Thanks for your immense patience :-)
>
> These are some additions to my proposal above, based on your inputs:
> Status of current 'creation' code in django:
> The current code, for e.g. sql_create_model in
> django.db.backends.creation is
Hi Russell,
Thanks for your immense patience :-)
These are some additions to my proposal above, based on your inputs:
Status of current 'creation' code in django:
The current code, for e.g. sql_create_model in
django.db.backends.creation is a mix of *inspection* part and *sql
generation* part.
On 03/04/2012, at 5:06 AM, j4nu5 wrote:
> Hi Russell,
>
> Thanks for the prompt reply.
>
> * You aren't ever going to eat your own dogfood. You're spending the GSoC
> building an API that is intended for use with schema migration, but you're
> explicitly not looking at any part of the
Hi Kushagra,
On the whole, I think this proposal is looking fairly good. You're high-level
explanation of the problem is solid, and you've given enough detail of the
direction you intend to take the project that it gives me some confidence that
you understand what you're proposing to do.
I
Here is a revised proposal.
Abstract
--
A database migration helper has been one of the most long standing feature
requests in Django. Though Django has an excellent database creation helper,
when faced with schema design
19.3.2012 13:15, Andrew Godwin kirjoitti:
On 19/03/12 11:08, Jonathan French wrote:
On 18 March 2012 23:33, Russell Keith-Magee > wrote:
> 2. An inspection tool that generates the appropriate python code
after
> inspecting models and
On 19/03/12 11:08, Jonathan French wrote:
On 18 March 2012 23:33, Russell Keith-Magee > wrote:
> 2. An inspection tool that generates the appropriate python code
after
>inspecting models and current state of database.
On 18 March 2012 23:33, Russell Keith-Magee wrote:
> > 2. An inspection tool that generates the appropriate python code after
> >inspecting models and current state of database.
>
> The current consensus is that this shouldn't be Django's domain -- at
> least, not in
On 18/03/2012, at 7:38 PM, Kushagra Sinha wrote:
> Abstract
> --
> A database migration helper has been one of the most long standing feature
> requests in Django. Though Django has an excellent database creation helper,
Abstract
--
A database migration helper has been one of the most long standing feature
requests in Django. Though Django has an excellent database creation helper,
when faced with schema design changes, developers have to
14 matches
Mail list logo