[NotarySojac]

Hey, I've spent the last week or so coming up with a way to transfer a whole ton of database tables to my rails site. I'm tremendously excited, but I just realized I have a major problem ahead of me regarding the naming of tables.

If I have a table named "AccountsPayableLedger" which is basically a listing of transactions where the owner of the Web Application has to make payments to suppliers/etc.

To setup the table (and the model, I'll need that, right?) I would run a command like this:

rails g model AccountsPayableLedger  P_Id:integer VendorID:integer TransactionNumber:integer Invoice:integer TransactionDate:date TransactionType:text Amount:decimal Comment:text CheckNumber:integer

That will create a table named AccountsPayableLedgers, right? That would be bad news because I'd have to make a special exception for when I synchronize the tables. Is there a way (and is it a sound practice) to force the table name to be just plain old AccountsPayableLedger?

[sepp2k]

Actually it would create a table named accounts_payable_ledgers, not AccountsPayableLedgers (though either way it's not what you want, so it doesn't really matter).

Quote

Is there a way (and is it a sound practice) to force the table name to be just plain old AccountsPayableLedger?

Yes, you can put the line set_table_name "AccountsPayableLedger" into your model, so it will use AccountsPayableLedger as the table name. You also need to change the migration accordingly.

[Karel-Lodewijk]

Have you considered just using plain sql to do this ?

Rails does use a sql database as a backend.

• Set the rails application up the way you want it to.
  
• Open the database your rails application uses in a sql console
  
• Import the database dump you have, most of the time data dumps use commands that are common to all sql versions, so it should work fine.
  
• Then from an sql console, play around with sql queries to get your data from format a to format b. After all sql is a pretty powerful data manipulation language on it's own.
  
• Drop the now obsolete tables.

This post has been edited by Karel-Lodewijk: 01 January 2012 - 08:07 PM

[NotarySojac]

It's kind of a head scratcher of a situation because the "Legacy database" has some legacy software still making updates to it. So I need to periodically (at the end of the day) send the new data to the rails app. And that legacy software is on its way to being replaced. So the data goes from

16bit QBASIC embeded database --> Access Database (via C#) -->
CSV/TCP (via C#) --> MySql (rails!)

I'm hopeful that eventually the rails application will be able to take the place of the 16bit QBASIC application, but it's a very intricate piece of software to code so in the meantime I'm just going to build the rails app to be a read-only version of the QBASIC program and then prepare it to be read/write and cut the QBASIC out of the loop (and hours and hours of C# migration programming at that).

So anyway, the problem was that I wanted to end up with a set of properly named tables at the end (the MySql stage) AND have the ability later on to interact with the tables through Models and all that fun rails stuff.