we have two databases in our project, one for primary and one for backup. Both of the databases have exactly same data.
we have used EF designer model to get SP's from db. we call any method by just using object.spName . This is working perfectly if we have only one db. But since we have multi db system i need to make sure that insertion operation works on both db and select queries can be run from primary only and backup will be used to get records only if primary is down.
What is the best approach to get this working, or how can i specify multiple db in same connection string
You don't want to do this on the application layer... You should look into database technologies like replication to perform this, or use native database backups and restore them on a schedule
Imagine an error occurs between the first and second, or someone does a manual query - your dbs will be out of sync.
Related
I am attempting to create a custom command that will migrate user data from one database to the next, This database is not normalized, very legacy, very badly made.
All of that is fine, but I am unsure, in a custom laravel command of how to connect to a different database and do select commands and get back collections of data, like you would if you were doing User::all().
I wont have models for this other database, the application that uses said database is written in php 5.2.
How can I create a custom command that does select statements to another database? All the answers I find are for creating migrations to another database.
You can define multiple database connection configurations in your config/database.php file, then use DB::connection('connection_name_here') to run queries on specific connections.
For example:
DB::connection('first_db')->select("...");
DB::connection('second_db')->select("...");
More information on multiple connections can be found in Laravel's documentation: https://laravel.com/docs/5.7/database#using-multiple-database-connections
There are a number of questions here about adding columns to a model via rails migration files and a rake db:migrate.
In this case, however, the application is basically a CRUD on top of an existing SQL Server database that is generated by another application. That is, I don't control it. Those who do control the database have added several columns to a table.
What I need is for the Rails app to respect the changes made to the database without assuming it has full control over the table structures.
I've tried plugging the new fields into the model and controller files, but sql queries give TinyTDS errors saying the new fields don't exist. Queries by hand (via SQL Server Management Studio) work fine. What am I missing? Why doesn't Rails recognize the new fields when they appear in the table model?
UPDATE:
It turns out that the problem is more subtle than I though when asking the initial question. As background, this application is set up with two databases, one production, one development/test. They are both on the same SQL Server database server. What's actually happening with the missing columns is that the Rails app pulls from production no matter what environment I use. Even when I change both environments to use the same development database (in database.yml), the app continues to query the production database.
Perhaps this is a problem between Rails and SQL Server. I've cleared all caches and cleared all database connections, but it makes no difference. It seems that the Rails app is caching the database name and login info somewhere.
One day I'd like to get this fixed, but for now I'll simply move the development database to another server for testing.
ActiveRecord has a cache of the table fields. If you want to reset the cache for a model without restarting your application, you can do:
MyModel.reset_column_information
What would be an good way of storing application options in a neo4j database?
I have few settings that I would like to persist for an application.
In an SQL database, I would create a table with 2 columns (name and value) (and perhaps a few more, but you get the idea).
In neo4j I'm thinking about a single node (with a 'Config' Label) and have an attribute for each setting I want to store.
Is this a recommended way of doing this? Feels kind of strange for a graph database, since this node will not have any relationship.
That is a perfectly fine way to do what you want.
I have a Rails app and a Sinatra app, sharing the same database. The Sinatra app uses ActiveRecord.
Can I run migrations from within each app, as if they were in the same app? Will this cause any problems?
The schema.rb file in the Rails app tracks the current migration via
ActiveRecord::Schema.define(:version => 20121108154656) do
but, how does the Sinatra app know the current version the database?
Rails 3.2.2, Ruby 1.9.3.
The version column in the schema_migrations table equate to the time stamp on the front of the ruby migration file example: 20130322151805_create_customers.rb So if two ore more applications are contributing to the schema_migrations table roll backs will not be possible if rails can't find the down() method (because it will not find a migration file contained in another app ie db/migrate/...)
I have a current situation that is exactly this and I have opted to have a master ActiveRecord app that manages migration and data conversions as our database evolves. Keep in mind that part of the deal is to keep models up to date as well. This has been time consuming so we are considering breaking apart the DB in to business domains and providing APIs (JSON) to query support data for another application. This way each application manages it domain and is responsible for exposing data via API.
regards.
If you connect both applications to the same database you should be able to run migrations on it but I strongly suggest you use another option since you will almost surely hit a wall at one time or another:
split the database in two if possible with each application responsible for its own database /migrations.
have one application considered the "master" database and use another database for the data specific to the second application but make it connects to both database (each application still only apply migrations to one database)
If you need to share data between multiple applications another option is to implement a REST service in one and use it on the other, you can have a look at the grape gem for a simple way of doing so.
Edit: I realize I forgot to speak about the activerecord migration, there is no longer any "version" of the schema, what activerecord does is that it read all your migration filename, extract their identifier (the starting part) and check if they have already been applied so in theory you can run migrations from two applications on the same database provided they don't interfere.
But if both migrations act on the same tables you will almost certainly run into big troubles at one point.
I disagree with Schmurfy, even if his presented options are valid, its a bit of an overkill to share data through REST (granted, its pretty easy to implement with ruby / rails).
If your case is simple you could just use one database from both apps, and since you use AR in both of them you have no problems with versioning, AR takes care of that.
Also i dont know what happens if you run db:migrate from both apps simultaniously if you use a inferior dbms like mysql which does not allow DDL in a transaction, certainly nothing good..
Also it would bother me to look which app needs what column and not have the migrations in one place. You could use a shared repository to manage the migrations from both apps.
Rails migrations store current database version in schema_migrations table in the database. So both of your apps will be able to check the current version.
The version numbers are timestamps, so there shouldn't be any problem with duplicate values, as it'll be almost impossible to generate two migrations at the exact same millisecond. So you should be fine here.
The only problem I see is that when you rollback a migration in one app, it'll set the db to the previous known version and I'm not sure if it will pick the previous one from the db (which could be from the other app), or the number from the previous migration file. You may want to test that scenario to make sure.
I decided to put all migrations in the Rails app because:
Since there is only one database
Rails manages migrations
This has worked well.
This simplifies the system because all migrations are stored in one place. And, the Sinatra app doesn't need to know about them anyway.
This is my first post so please be patient with me... :)
I am learning rails at the moment and took an internal project to help me and get proper handson practice.
The situation is like this:
We have an existing MS SQL Server 2000 DB with bunch of customers. Usual stuff.
I don't know who designed it but there is a huge table "Customer" where all the details are.
Soon we'll be moving customers out to a new company and need to track the movement.
So the application should have the snapshot of the movement details for a particular customer: whether he was called on the phone, talked to or contacted by other means. Notes of the conversation. Whether he agreed to move. Etc ...
So the original customer data should be pooled from MS SQL and all the new tracking data should be in proper new rails DB.
I was considering few things:
1. Pooling customer records from old DB and doing the rest of the work in the new one.
This one no good as my research shows that rails cannot work with two DBs at the same time.
2. Connecting to just old MS SQL and doing all the work there creating new necessary tables.
This one seems to be a lot of trouble. "odbc" adapter gives me errors. "sqlserver" adapter does not work with mssql 2000
Plus, I predict lots of troublew working with existing MS DB.
3. This method I think is the most rational.
Dump the customer table from the old MS SQL DB to CVS and import it to the new sqlite db created for the rails app.
Please let me know if you think of other methods to solve this problem.
With the third method I still see many problems which I would like help if possible.
For instance, rails creates additional fields in the table so the data import might not work. Or am I mistaken?
Is the third method sounds doable for you? Do you see any pitfalls. Suggestions?
Thanks very much.
So unfortunately, ruby doesn't work great on windows, and MSSQL is probably the worst choice for a rails db. Given that I could deploy on MySQL or PG on linux, I would export the data from the old db, and totally start fresh, so write a data import script that shapes things the way rails likes. First step would be to move towards rails conventions, so a Customer model will have a customers table with an auto incrementing primary key field called id that is an integer. All fields use "wide case" (all lower case, with underscores seperating words), and audit fields on all tables that are datetime, and called created_at / updated_at. Definately a pain (especially if you are new to rails), but you will have a hellish time if you try to fight convention and are not at least moderately comfortable with the platform. IMO sqlite is a bad choice for anything other then an app that wont store much data and will be used by only one person.