Trying to build rails 3.2 app over existing mysql db - mysql

I am trying to figure out how to build a rails app on top of an existing mysql db. I think the best method would just be to create a migration with the same layout as the existing db, but I am not quite sure how to do this, then connect it. I am aware of this post Building Ruby on Rails App with an existing Mysql db
but am still unsure; do I just do this but with the columns I need? Also the main answer to this question is saying that I should make my db a csv and then import it, does anyone have a tutorial or gem they recommend for that?

I have not done this exact task personally although when I modify my databases manually through my mysql client and create backup tables for example, they magically appear in my schema.rb file later down the road when I run some future migrations.
So the following post should help or at least point you in the right direction:
http://tianhsky.ueuo.com/blog/2012/02/20/generate-schema-rb-from-existing-database/

Before that, try to learn more about rails and it's conventions. Probably you'll need to adapt your database scheme.
Or you could start an application and then import the data, even by SQL or by CSV as you mentioned. Migrating data can be a tedious work, but a necessary one.
You can check this gem to see if it helps on your case, because it will depend on your actual schema.

Related

Do I need to create DB migration, if I have a designed DB in MySQL?

I designed a database in MYSQL. Now I want to connect that with my Laravel application. But after researching, I understand that I need to migrate the database into Laravel by creating migration tables. But doing the same thing that I did in MySQL is tedious. I think there is another way to do the stuff. After searching I got this article from stackoverflow, but this is related to yii framework. I think someone knows here the solution of my problem.
I don't see a problem here, you can just connect Laravel to your DB (by editing your .env file) without any problems, migration files are just an easier way to design and implement your tables (also altering your tables' scheme on production is a very useful usage for migrations), but with that being done then no further actions are required, and you are good to go!
it's pretty obvious, you can update the database setting in the .env file and use DB::table('your_table_name') and get whatever query you want.
The upside of using migrations is that the exact same database can be created on different systems (ex: co-workers or acceptance/production servers).
Laravel migrations have an up and a down function so you can rollback to a specific version if something went wrong, very usefull when publishing your code.
That being said, co-workers could also review the database changes and for example hint at using more indexes and foreign keys.
As the other comments said, it's not a requirement you use migrations but it has considerable advantages versus creating and updating the database manually.

What is the correct way of structuring mySQL code in a nodejs projects?

I have been working on a project lately and using node as my back-end but instead of Mongodb I am using MySQL as my DBMS as I will need it in my project but I am having trouble organizing MySQL queries and can't find a good solution that helps me structure my code and files right. And another issue is that I don't know when to close my connection or if leaving it is a good practice or not.
NOTE: I already use express generator for generating my file architecture my only problem is where to place the MySQL related code and what are the best practices for a clean code.
You can create a model folder and add all your 'tables'.js there.
You can also create a DB.js file, so you can use Mysql from Nodejs and also manipulate it from the prompt:
Model Exemple
I.e of DB connection:
DB Connection
You can create tables on the way below. ID's, creating date and updated date are created automatically by Nodejs, so you don't need to worry about.
how to create a table
You also will need to download mySQL (npm install MySQL --save) and to interact with MySQL (selects, deletes,...)
Another way is create a repository.js and add SQL queries there, but is not really useful since you are using nodejs and it provides you these queries.

is it ok to change the database table schemas created from rails using mysql?

I created some tables using rails. Now I want to modify the structure of a few of them. I know it can be done using rails migration. But i was wondering if it would cause any anomaly in the rails app if I modify the schemas using mysql rdbms?
Doing such changes through a migration has the advantage of not losing the changes if you decide to recreate/remigrate the database.
Also it serves as documentation. Imagine if your coworker altered some tables sneakily (and then you both forgot about it).
Technically, updating schemas directly in the database should work, but don't do it.
To add to Sergio's point, you're missing a simple fact - Rails' migrations create the famous db/schema.rb file - from which your migrations pull all their data.
The importance of schema.rb is overlooked - it is one of the most crucial aspects of your application.
db/schema.rb
The schema gives all your migrations a version of your DB to change / add to. Each time you perform a migration, Rails changes the schema file to ensure it has a "blueprint" of your db stored on file.
The schema is then able to rebuild the database using such methods as rake db:schema:load (ONLY RECOMMENDED FOR NEW INSTALLS -- DELETES PREVIOUS DATA)
So whilst there's no problem setting up the db using the db's own native tools, I recommend against it. You need to keep your migrations up to speed so that Rails can build the appropriate tables from its schema.

Model design in Django. Is South the only way to have any bit of freedom in changes in model?

Hi I am newbie to django development, but anyway I will try in this question do not to be generall.
I have strange problems while designing my model. I want to make a lot of changes - like alwyas in the begining of the project. The problem is that after one syncdb I can not change anything in model, unless I create completly new database and link it in settings.py. What is pretty strange I even can not delete this old database. When I try do it from Sequel Pro it freezes.
I googled a bit, and is really South or similar tool the only option to have some fredoom in models desgining phase in django?
I know that this mechanisms are for certain purpose like keeping data consistency on existing project, but I just started my development and have even 0 records in all the tables.
I user in my development 5.6.13 MySQL Community Server, Django 1.5. All runing on OS X.
South is a great tool for migration or if you have made some changes. It may take a little time to get through for the beginners as it was for me too, but eventually you will like it. Other than that as per your question, you can use flush, which replaced reset in django 1.5. And please remember, that it flush all the database and not just the app.
python manage.py flush
But luckily reset has been ported back in here. All you have to do is install, and add it in the settings. And then run
python manage.py reset appname
Hope this helped!
OK. Partially I found answer here: Django: Change models without clearing all data?
SAYING: "syncdb will only create tables for models which have not yet been installed. It will never issue ALTER TABLE statements to match changes made to a model class after installation. Changes to model classes and database schemas often involve some form of ambiguity and, in those cases, Django would have to guess at the correct changes to make. There is a risk that critical data would be lost in the process. If you have made changes to a model and wish to alter the database tables to match, use the sql command to display the new SQL structure and compare that to your existing table schema to work out the changes."
OK. I see that I can run python manage.py sql <app_name> then should I paste it in python manage.py dbshell?
via dbshell I managed to delete whole database, what was not possible in Sequel Pro.
python manage.py dbshell
and then via MySQL:
drop database <db_name>;
And why the database when accesing from Sequel Pro is froozen?
I was trying to avoid South, because there were many opinions that it is confusing, and time consuming to learn. After sometime I look back on SOUTH and I have to say:
It is completely WORTH learning it, what is not hard at all.
It is very nice tool for dealing with model, which changes dynamically.
I can propose a nice tutorial video to all newbies, who will consider either it is or not worth to learn. http://www.youtube.com/watch?v=7yCmAhthkMk

Migrating subsets of production data back to dev

In our rails app we sometimes have db entries created by users that we'd like to make part of our dev environment, without exporting the whole table. So, we'd like to be able to have a special 'dev and testing' dump.
Any recommended best practices? mysqldump seems pretty cumbersome, and we'd like to pull in rails associations as well, so maybe a rake task would make more sense.
Ideas?
You could use an ETL tool like Pentaho Kettle. Once you have initial transformation setup that you want you could easily run it with different parameters in the future. This way you could also keep all your associations. I wrote a little blurb about Pentaho for another question here.
If you provide a rough schema I could probably help you get started on what your transformation would look like.
I had a similar need and I ended up creating a plugin for that. It was developed for Rails 2.x and worked fine for me, but I didn't have much use for it lately.
The documentation is lacking, but it's pretty simple. You basically install the plugin and then have a method to_sql available on all your models. Options are explained in README.
You can try it out and let me know if you have any issues, I'll try to help.
I'd go after it using a Rails runner script. That will allow your code to access the same things your Rails app would, including the database initializations. ActiveRecord will be able to take advantage of the model relationships you've defined.
Create some "transfer" tables in your production database and copy the desired data into those using the "runner" script. From there you could serialize the data, or use a dump tool, since you'll be dealing with a reduced amount of records. Reverse the process in the development environment to move the data into the database.
I had a need to populate the database in one of my apps from remote web logs and wrote a runner script that fired off periodically via cron, ftps the data from my site and inserts the data.