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
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
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) design is to have functions like "create_table"
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:/
I have been updating the Wiki a bit (
https://code.djangoproject.com/wiki/SchemaEvolutionDesign). If you see the
linked page about the design, it's based on a general approval I got from
Russell. I haven't finished writing it up, but it has been in the 60's and
70's in Wisconsin in March. Needless
Check the edit dates on that wiki -- most of the content on that page is
historical, reflecting discussions that were happening over 3 years ago.
There have been many more recent discussions.
Sincere apologies. The page says "Last modified 10 days ago". I thought it
was pretty recent and didnt che
On Mar 19, 2:32 pm, Jani Tiainen wrote:
> Here I would like to rise my concern - specially being long time Django
> and Oracle user.. =)
>
> First at all everyone can get hands on Oracle Express database, free of
> charge standard Django stuff works in it very well. Geodjango doesn't
> work with i
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,
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 r
21 matches
Mail list logo
