On Wednesday 25 July 2007 19:34:50 Marco Mariani wrote:
> Anton V. Belyaev ha scritto:
> >> again, im not opposed to this feature and ill patch in an
> >> adequate (and fully unit-tested) implementation. but have you
> >> actually ever *had* this problem? or is it just hypothetical ?
> >
> > For
Anton V. Belyaev ha scritto:
>> again, im not opposed to this feature and ill patch in an adequate
>> (and fully unit-tested) implementation. but have you actually ever
>> *had* this problem? or is it just hypothetical ?
>>
>
> For example, a developer modifies the metadata and checks in.
On Jul 25, 2007, at 12:02 PM, Anton V. Belyaev wrote:
>> again, im not opposed to this feature and ill patch in an adequate
>> (and fully unit-tested) implementation. but have you actually ever
>> *had* this problem? or is it just hypothetical ?
>
> For example, a developer modifies the metada
On 25 июл, 19:38, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jul 25, 2007, at 4:57 AM, Anton V. Belyaev wrote:
>
>
>
> > I believe this should be done somehow automatically. Because everyone
> > needs this. There should be two separate disjoint options:
>
> > 1) Autoload, when working with pr
On Jul 25, 2007, at 4:57 AM, Anton V. Belyaev wrote:
>
> I believe this should be done somehow automatically. Because everyone
> needs this. There should be two separate disjoint options:
>
> 1) Autoload, when working with previously created database for rapid
> start. Columns arent specified at
> t = Table('mytable', meta,
> Column(...)
>
> )
>
> someothermeta = MetaData()
> t2 = Table('mytable', someothermetadata, autoload=True,
> autoload_with=)
>
> assert t.compare(t2)
I believe this should be done somehow automatically. Because everyone
needs this. There
On 7/24/07, svilen <[EMAIL PROTECTED]> wrote:
>
> > >> assert t.compare(t2)
> > >
> > > yes i was hoping for such method (:-)
> > > And the best will be if it can produce a list/ hierarchy of
> > > differences, which then programaticaly can be iterated - and
> > > checked and resolved or raised hi
On 7/25/07, svilen <[EMAIL PROTECTED]> wrote:
>
> > i just saw there is some usagerecipe ModelUpdate in the wiki, may
> > be a good start point:
> > http://www.sqlalchemy.org/trac/wiki/UsageRecipes/ModelUpdate
> >
> and this one:
> http://www.sqlalchemy.org/trac/wiki/UsageRecipes/AutoCode
As I sa
> i just saw there is some usagerecipe ModelUpdate in the wiki, may
> be a good start point:
> http://www.sqlalchemy.org/trac/wiki/UsageRecipes/ModelUpdate
>
and this one:
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/AutoCode
--~--~-~--~~~---~--~~
You received
i just saw there is some usagerecipe ModelUpdate in the wiki, may be a
good start point:
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/ModelUpdate
> > >> assert t.compare(t2)
> > >
> > > yes i was hoping for such method (:-)
> > > And the best will be if it can produce a list/ hierarchy of
>
> >> assert t.compare(t2)
> >
> > yes i was hoping for such method (:-)
> > And the best will be if it can produce a list/ hierarchy of
> > differences, which then programaticaly can be iterated - and
> > checked and resolved or raised higher.
> >
> >> but why not just use autoload=True across the
On Jul 24, 2007, at 11:07 AM, svilen wrote:
>
> On Tuesday 24 July 2007 17:30:27 Michael Bayer wrote:
>>
>> such a feature would make usage of table reflection, and then a
>> comparison operation, along the lines of :
>>
>> ...
>>
>> assert t.compare(t2)
> yes i was hoping for such method (:-)
>
On Tuesday 24 July 2007 17:30:27 Michael Bayer wrote:
>
> such a feature would make usage of table reflection, and then a
> comparison operation, along the lines of :
>
> ...
>
> assert t.compare(t2)
yes i was hoping for such method (:-)
And the best will be if it can produce a list/ hierarchy of
On Jul 24, 2007, at 9:59 AM, Anton V. Belyaev wrote:
>
> Of course db modification is hard. It cant be done completely
> automatically. For now I would like SQLAlchemy just to signal somehow
> when its definitions are different from already existing db tables.
> When I do create_all() it checks
On 24 июл, 17:34, svilen <[EMAIL PROTECTED]> wrote:
> On Tuesday 24 July 2007 16:22:43 Anton V. Belyaev wrote:
>
> > Hey,
>
> > I believe there is a common approach to the situation, but I just
> > dont know it.
>
> > Let say, I have some tables created in the DB using SQLAlchemy.
> > Then I mod
On Tuesday 24 July 2007 16:22:43 Anton V. Belyaev wrote:
> Hey,
>
> I believe there is a common approach to the situation, but I just
> dont know it.
>
> Let say, I have some tables created in the DB using SQLAlchemy.
> Then I modify Python code, which describes the table (add a column,
> remove a
16 matches
Mail list logo
