I am still not understanding how you manage your migrations. How do you 'I just make sure all<br>
migrations happen from within the Rails codebase'? Is there a way to exclude legacy tables from a Rails environment?<br><br><div class="gmail_quote">On Fri, Jan 8, 2010 at 11:37 AM, David Salgado <span dir="ltr"><<a href="mailto:david@digitalronin.com">david@digitalronin.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm in much the same position as Andy Stewart. My app. started life in<br>
PHP, and I've gradually migrated most of the code to Rails, while<br>
keeping most of the original schema.<br>
<br>
table_name, primary_key and liberal use of Dr. Nic's<br>
composite_primary_keys gem do the trick for me, but YMMV of course.<br>
<br></blockquote><div><br>Hopefully I do not have any compposity key :-)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Migrations haven't been a problem for me at all, I just make sure all<br>
migrations happen from within the Rails codebase, even if the feature<br>
the migration is for is being implemented in the PHP code.<br>
<br></blockquote><div><br>Do you mean implementing migrations in PHP? If yes I wouldn't do that.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The views idea is interesting, though.<br>
<br>
Best of luck<br>
<br>
David<br>
<br>
<br>
<br>
2010/1/8 Andrew McDonough <<a href="mailto:andrew@andrewmcdonough.co.uk">andrew@andrewmcdonough.co.uk</a>>:<br>
<div><div></div><div class="h5">> Disclaimer: my suggestion might be a really bad idea (I only just<br>
> tried it and have certainly never used it in production). I'd like to<br>
> hear what other people think though, as it's something I've considered<br>
> in the past to port our numerous legacy PHP apps to rails. It does<br>
> appear to work though.<br>
><br>
> Use MySQL views:<br>
> You could use MySQL views to create rails friendly views of the<br>
> database tables. You would then write the classes assuming that<br>
> everything is named as rails likes it. For example, assuming two<br>
> simple tables in the old database, "user" and "dept", you could create<br>
> views called users and departments:<br>
><br>
> CREATE TABLE user (<br>
> userID int(11) NOT NULL auto_increment,<br>
> name varchar(255),<br>
> deptID int(11),<br>
> PRIMARY KEY (userID)<br>
> ) TYPE=MyISAM;<br>
><br>
> CREATE TABLE dept (<br>
> deptID int(11) NOT NULL auto_increment,<br>
> name varchar(255),<br>
> PRIMARY KEY (deptID)<br>
> ) TYPE=MyISAM;<br>
><br>
><br>
> CREATE VIEW users as select userID as id, name, deptID as<br>
> department_id FROM user;<br>
> CREATE VIEW departments as select deptID as id, name FROM dept;<br>
><br>
> Then in your model:<br>
><br>
> class Department < ActiveRecord::Base<br>
> has_many :users<br>
> end<br>
><br>
> class User < ActiveRecord::Base<br>
> belongs_to :department<br>
> end<br>
><br>
> I've tried creating, saving and loading both of these entities and<br>
> querying the associations between them, and it appears to work. The<br>
> advantage of this is you could write clean model code, and assume well<br>
> named tables, meaning if you ever decide to migrate the database to a<br>
> rails naming convention, you wouldn't need to touch your code. The<br>
> disadvantages are that you would end up with twice as many table<br>
> views, and you would need to maintain two things for each table (e.g.<br>
> adding a field would mean adding it to both the table and the view).<br>
> Again, I have only tested this for two simple tables. It might break<br>
> for more complex schemas, but I thought it was worth investigating.<br>
><br>
> Regards,<br>
><br>
> Andrew McDonough<br>
><br>
><br>
><br>
> 2010/1/8 Andrew Stewart <<a href="mailto:boss@airbladesoftware.com">boss@airbladesoftware.com</a>>:<br>
>><br>
>> On 8 Jan 2010, at 10:33, Riccardo Tacconi wrote:<br>
>>><br>
>>> Yesterday I decided to refactor a page developed in PHP with Rails. I am<br>
>>> using two MySql databases, one for the PHP, one for Rails. Now I am not sure<br>
>>> if I should use only one database or two. The DB for PHP has name in the<br>
>>> singular form (dept, user, article...), the primary keys are something like<br>
>>> 'deptID', 'user_id', in few words is an old rubbish inherited DB.<br>
>><br>
>> I am working in a similar situation where I am running an old Mambo (PHP)<br>
>> site alongside a new Rails site, while slowly moving functionality from the<br>
>> former to the latter.<br>
>><br>
>> I have a single MySQL database containing both the PHP system's tables and<br>
>> the Rails app's tables. This way I only need to connect to a single<br>
>> database, which is the way Rails likes it. To avoid table name clashes I<br>
>> prefixed all the Rails app's tables with a simple prefix, configuring<br>
>> ActiveRecord appropriately (c.f. the table_name_prefix method).<br>
>><br>
>> Have a class for each PHP table you need to use, and use ActiveRecord's<br>
>> table_name and primary_key methods to cope with the old table names. I do<br>
>> this and it all works perfectly.<br>
>><br>
>> When I want to move functionality and data from PHP-land to Rails-land, I<br>
>> use Tim Riley's marvellous acts_as_importable plugin. He came up with an<br>
>> excellent pattern for migrating data, and for my system it works very well.<br>
>><br>
>> <a href="http://github.com/timriley/acts-as-importable" target="_blank">http://github.com/timriley/acts-as-importable</a><br>
>><br>
>> Regards,<br>
>><br>
>> Andy Stewart<br>
>> -------<br>
>> <a href="http://airbladesoftware.com" target="_blank">http://airbladesoftware.com</a><br>
>><br>
>> _______________________________________________<br>
>> Chat mailing list<br>
>> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
>> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
>><br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Riccardo Tacconi<br>VIRTUELOGIC LIMITED<br><br><a href="http://www.linkedin.com/in/riccardotacconi">http://www.linkedin.com/in/riccardotacconi</a><br><a href="http://riccardotacconi.blogspot.com/">http://riccardotacconi.blogspot.com/</a><br>
<a href="http://twitter.com/rtacconi">http://twitter.com/rtacconi</a><br>Linux user: #400461<br>