short poll: schema evolution interface

[pub...@kered.org]

regarding how a developer would interact with any schema evolution
implementation...would you prefer / see as more natural:

1) a commandline util only (via manage.py)
2) a web-based UI only (via the admin screens)
3) both

(remember that we're likely talking about a multi-step upgrade process for
more complicated modifications)

if {2,3}, would you want the application to block (or redirect to a
holding page) all incoming requests once it detects an update is needed?

aux question: my personal experience is that you should lock down alter
table permissions away from the application's credentials. is this common
in the django community?

thanks!
derek

[James Bennett]

On 5/31/06, pub...@kered.org <pub...@kered.org> wrote:
> 1) a commandline util only (via manage.py)

This would maintain consistency with the rest of Django's management
options; I'd always figured that at least part of the schema evolution
interface would involve manage.py.

--
"May the forces of evil become confused on the way to your house."
-- George Carlin

[Bryan]

> 1) a commandline util only (via manage.py)

+1

[John Melesky]

James Bennett wrote:
> On 5/31/06, pub...@kered.org <pub...@kered.org> wrote:
>> 1) a commandline util only (via manage.py)

+1

-johnnnnnn

[Honza Král]

+1 on 1) ;)

--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585

[Ilias Lazaridis]

pub...@kered.org wrote:
> regarding how a developer would interact with any schema evolution
> implementation...would you prefer / see as more natural:
>
> 1) a commandline util only (via manage.py)
> 2) a web-based UI only (via the admin screens)
> 3) both

of course i would prefere to have both available.

but as the time is limited, I would prefere to see the efforts going
into a cmd-line utility.

so 1) (due to the limited time budget)

> (remember that we're likely talking about a multi-step upgrade process for
> more complicated modifications)
> if {2,3}, would you want the application to block (or redirect to a
> holding page) all incoming requests once it detects an update is needed?

wouldn't this be neccessary for a cmd-line update, too?

> aux question: my personal experience is that you should lock down alter
> table permissions away from the application's credentials. is this common
> in the django community?

I don't know about the django community, but personally, I would remove
all permissions which could become critical to application integrtiy.

Possibly the evolution tool should provide a mechnism to unlock them.

.

--
http://lazaridis.com