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

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.

Related

Do i really need to define models in sequelizejs?

I'm playing around with expressjs for a while and now the time has come to connect to a mysql database. Now i'm searching for a way to write and retrieve data from it. Normally i'm creating the database tables with MySQL Workbench. I'm using MySQL because of the ability of using ForeignKeys. Couldn't figure out yet how to do it in other database types...
Currently i'm more used to medoo for PHP. It only connected to a database and gave me the ability to access it in an object oriented way.
Is there a similar module for nodejs out there?
Try knex for a sql-builder library, it's pretty solid and looks sort of similar to medoo (but it uses Promises and is asynchronous).

meteor reporting of data in existing mysql db. how?

I'm trying to make some reports using meteor and raphael js. I have to report data from an existing MySQL database. I do not wish to write to that database. I need only the "R" from CRUD.
I have thought of various manual ways of: exporting .csv files from the MySQL db via the application itself (Limesurvey) and using mongoimport to populate a MongoDB collection, and then do my CollectionName.find() etc in Meteor.
or perhaps some way of exposing REST full endpoints only to consume data, and use the http package for Meteor.
Is there a good clean solution for using existing SQL data in a Meteor JS application?
How can one use pre-existing SQL data?
(I've no problem with duplication in MongoDB, mind you. however it has to be...)
Thank You
You can do it without any duplication completely from inside Meteor, but you will have to jump through a couple of hoops.
Firstly, use the mysql npm package to query the SQL database. Though Meteor provides Npm to require node packages, I find that using meteor-npm is an easier. Then to do the "R"eading form MySQL, create a Meteor.method on your server which queries the MySQL directly.
Then the second problem is that the mysql package is completely asynchronous. Hence, the execution of the SQL query returns value in a call back and by that point, your Meteor.method call would return leaving the client with an undefined. To fix that issue, we can use Future.
There are a couple of ways of smoothing over this step:
Using `meteor-sync-methods
Spinning out your own version from advice from the issue to allow this natively
Use this easy to implement one-time pattern: "fence has already activated -- too late to add writes"
Hope that helps.

Trying to build rails 3.2 app over existing mysql db

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.

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.

How to collaborate on mysql schema?

I'm working with another dev and together we're building out a MySQL database. We've each got our own local instances of MySQL 5.1 on our dev machines. We've not yet been able to identify a way for us to be able to make a local schema change (eg: add a field and some values for that field) and then export some kind of script or diff file that the other can import in. I've looked into Toad and Navicat's synchronization features but they seem oriented towards synchronizing between two instances, not an instance and an intermediate file. We thought MySQL Workbench would be great but this but the synchronization feature just seems plain broken. Any other ideas? How do you collaborate with others on the schema?
First of all put your final SQL schema into version control. So you'll always have a version of it with all changes. It can be a plain SQL file. Every developer in the team can use it as starting point to created his copy database. All changes must be applied to it. This will help you to find conflicts faster.
Also I used such file to create a test database to run unit-tests after each submit. So we were always sure that production code is working.
Then you can use any migration tool to move changed between developers. Here is similar question about this:
Mechanisms for tracking DB schema changes
If you're using PHP then look at Doctrine migrations.