Ahh, OK. Last I heard the Propel migrations project wasn't moving
very fast (if at all). Good to see someone working on it - it's one
of the things that makes RoR a pleasure to use. If you want some
help, send me an email off-list.
On Aug 19, 2008, at 4:27 PM, Kris Wallsmith wrote:
>
> It's pretty much a rewrite. Take a look at the migration tasks and
> lib/
> propel/migration.
>
> Kris
>
> On Aug 19, 2008, at 4:19 PM, Jacob Coby <[EMAIL PROTECTED]> wrote:
>
>>
>> Are you integrating the Propel migrations code or coming up with
>> something new?
>>
>> On Aug 19, 2008, at 4:09 PM, Kris Wallsmith wrote:
>>
>>> Hi Thomas,
>>>
>>> My latest work on migrations has been in sfPropelPlugin. I don't
>>> have any plans to port this work back to
>>> sfPropelMigrationsLightPlugin.
>>>
>>> I will look into adding some sort of namespace functionality to the
>>> sfPropelPlugin migrations system in the coming weeks.
>>>
>>> Thanks,
>>> Kris
>>>
>>> On Tue, Aug 19, 2008 at 11:13 AM, Thomas Rabaix <[EMAIL PROTECTED]
>>>> wrote:
>>>
>>> Kris,
>>>
>>> I suppose you are the maintainer of this plugin.
>>>
>>> Can you tell us your plan for this current thread ?
>>>
>>> Other possibles improvements :
>>> - display migration currently being executed :
>>> $this->diag('Executing UP : '.get_class($this)); or
>>> $this->diag('Executing DOWN :' .get_class($this));
>>> - a remove column function : removeColumn($table, $column,
>>> $ignoreError = false)
>>> - a drop table function : public function dropTable($table)
>>> - a drop view function: public function dropView($table)
>>>
>>> Thomas
>>>
>>>
>>> On Thu, Aug 14, 2008 at 4:31 PM, Jacob Coby <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>> That would be very cool. It isn't always feasible to run the
>>> build-db
>>>> task when adding a plugin. It would be nice to be able to ./
>>>> symfony
>>>> migrate sfGuardPlugin instead of finding and running the generated
>>> sql
>>>> file.
>>>>
>>>> Ideally, sfMigrationsLight would have database-agnostic migration
>>>> commands instead of raw sql. That would make it truly useful for
>>>> plugin migrations.
>>>>
>>>> On Aug 14, 2008, at 10:16 AM, Kris Wallsmith wrote:
>>>>
>>>>>
>>>>> Hm, I suppose plugins could establish abstract schema namespaces
>>> with
>>>>> their own incrementing version number. That should allow plugins
>>>>> to
>>>>> maintain independent migration tracks.
>>>>>
>>>>> Instead of having only one column and one row, the "schema_info"
>>> table
>>>>> would add a unique namespace column and have many rows...
>>>>>
>>>>> Kris
>>>>>
>>>>> On Aug 14, 2008, at 3:33 AM, klemens_u <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>>
>>>>>> +1, it would be great to have this independently
>>>>>>
>>>>>> Klemens
>>>>>>
>>>>>> --
>>>>>> ullright - opensource business webapp - workflow and more -
>>>>>> http://www.ullright.org
>>>>>>
>>>>>>
>>>>>> On Aug 14, 10:08 am, "Thomas Rabaix" <[EMAIL PROTECTED]>
>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I think the migration system should manage plugin migration
>>>>>>> independently from the main projet. The idea behind is to easily
>>>>>>> update/install a plugin.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>
>>>>>>
>>>>
>>>> --
>>>> Jacob Coby
>>>> [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Thomas Rabaix
>>> Internet Consultant
>>>
>>>
>>>
>>>
>>>>
>>
>> --
>> Jacob Coby
>> [EMAIL PROTECTED]
>>
>>
>>
>>
>>>
>
> >
--
Jacob Coby
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
