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
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 t
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
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. Sin
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 migrat
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 hav
Less than a week remains for student application deadline. Can someone
please comment on the above revised proposal. Thanks a lot.
On Monday, 26 March 2012 01:29:35 UTC+5:30, j4nu5 wrote:
>
> Here is a revised proposal.
>
> Abstract
>
>
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 mailto:russ...@keith-magee.com>> wrote:
> 2. An inspection tool that generates the appropriate python code
after
> inspecting models and current state of database.
Th
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
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 the first instance. It mi
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,
14 matches
Mail list logo
