Is it safe to build a Yii application over a SQL Server database which is being used by another software?
The ideia is to migrate that desktop software for a WebApp but I must let the database structure untouched.
It's a quite complex database and I have very complex SQL Queries as well, so I should avoid DAO and AR. I've been looking for some information around the web but it's not clear to me how safe it will be this process. Should I build all the application with RAW SQL and be careful with it's implementation?
Can anyone of you show me the right path I should follow?
Thanks in advance
It is absolutely safe to do this, with Yii you can use any database structure you need. You'll only need to create your models based on your current database structure.
Here a quick guide to use Yii with SQLServer http://www.yiiframework.com/wiki/192/config-use-ms-sql-server-2005-2008/
You can use just plain SQL with Yii, have a look at http://www.yiiframework.com/doc/api/1.1/CDbCommand
But if you want more flexibility, I can recommend you the following way.
create an initial database migration, just execute() a plain SQL dump from your exisiting database.
create database migrations as you need them
apply migrations
develop
go to step 1. if you want to test with newer data and reapply migrations to your database
shut down old application
As your migrations are versioned with your application, you could eg. maintain a branch with the old db-schema and work parallel on an updated version with another db-schema.
Related
I have a database we use on some of our existing websites, sites were built in Yii framework by another developer so no Laravel, I have set up a new project using laravel but am looking for the best way to link up to that database and return the information.
linking to the database is easy enough, just change the database.php file but I am getting really confused with migrations part and how to call it into a webpage.
So what's the simplest way to go about doing this?
Migrations are used to create or modify database structure. Since you already have a database set up, you don't need to use migrations.
To get accustomed with Laravel I strongly suggest watching:
Laracasts - Laravel 5 Fundamentals
I also suggest you go over the entire Laravel Documentation just to get acquainted with all the framework has to offer.
In the midst of developing a Laravel 4 app, I've decided to start making use of Laravel's Migration feature.
Question: Should we write migrations for creating all the tables that we currently have in the database? Or do we only write migrations for future changes?
There is no complete right answer to this. It all depends on a lot of variables, like your style of development, how many people you're working with and in what kind of environment (single production DB? multiple dev DBs?), what your requirements with migrations are, etc. etc.
If you do decide to write migrations for the entire DB up until this point, you'll need to make sure that your migrations can handle any potential conflicts. Making use of Schema::has() and such to verify tables exist prior to attempting to create them, and such.
Alternatively, you can write migrations as if the DB has a clean slate, and enforce any devs to start with an empty DB prior to running migrations. This has risks, so be careful. Make sure you have backups in case your migration forgot something and you need to modify it.
So, TL;DR: Is using migrations for your entire structure part way through a project necessarily a bad thing? No. Is it right for your application? That entirely depends.
I'm looking for a good php framework with support for handling database migrations. Ideally I would like to be able to run a command that generates a migration script, one that updates the database with changes and can handle rolling back those changes. Is there anything out there that does this?
The Doctrine project supports migrations - http://www.doctrine-project.org/projects/migrations/2.0/docs/reference/introduction/en
Hmm, that documentation is a bit lacking, at least in the introduction. Hopefully it gets better as it goes on.
Whilst most popular in Symfony, this can easily be integrated into other frameworks or even used on its own.
Promising, but not yet have a stable version : https://github.com/fuel/fuel
There is a new php framework called Laravel and it has migrations the same way as ruby on rails. It seems so pretty!
You can find it at http://laravel.com/
Migrations Docs
In addition, the framework introduces the idea of bundles, what can give to your project a great modular view.
If you try it, tell us your experience! :)
symfony - http://www.symfony-project.org/
In symfony you can write database schema using ORM like Propel, it is independant from database driver. If you have a database already, you want to migrate to a different db, I think you can dump the db, change the db config, and re-import it to the new db. (though I have not tried it myself.)
There are much php framework over there that can use any database. For example Zend, Ci, Cake and many others. One thing you should do is change database type that's usually stored in configuration file. And then migrate your database manually. No framework that can generate migration script automatically. U can also use ESF for database migration
I need to load data from an old DB into a migrated schema of this DB using Doctrine migration system.
I guess Doctrine might help me in this process.
I tried and lost a few hours using ETL scripts programs, without success.
From my point of view I need to :
Create a DB with the V0 schema
Load the data from the old DB (schema are identical)
Migrate DB to latest version using Doctrine migration
Extract data
Load it in the new DB
WHat do you think of this process?
Do you think it is feasable using Doctrine?
I tried a few searches on Google without success.
I am currently reviewed the features of Doctrine_Core class.
Thanks for your help
Yes, it is possible to migrate data from one database to another using Doctrine.
It sounds like you're trying to do a one-time database revision and migration and that your applications are not currently written using Doctrine. In that scenario, database abstraction has little or no benefit, unless you're also rewriting the applications to use it.
If you have no prior experience using Doctrine then I seriously doubt that writing custom migration classes in it will be easier than doing it with whatever database API you are already experienced using. It makes sense to use the migration classes (some times) if you are already using Doctrine for your development. Otherwise it's another layer and API you don't need.
I'm using Doctrine 1.2, which has some nice features for migrations but also a number of bugs and omissions of expected functionality. Reportedly version 2 improves on this but I haven't used it yet.
I've deployed my symfony project to the server and now I wanna change the models inside schema.yml without reseting other unrelated database tables and keep the current data.
Is there any diff / upgrade feature for symfony propel project ?
Take a look at sfPropelSqlDiffPlugin (available from the plugin repository). I've been using it for quite a while and it has worked well for me. It's not perfect (it doesn't deal too well with non-standard stuff like specifying a sqltype in your schema, for example), but it has made life much easier for me.
Instead of trusting the plugin to do the actual execution of the diffed SQL, I prefer to do:
./symfony propel:build-sql-diff
This creates a SQL file in your data dir, which you can then inspect/edit prior to manually executing the script.
You can generate the sql by using the 'propel:build-sql' command. The result is a valid SQL file which you can import yourself.
In our very big project we just keep track of the SQL itself. We build the models and generate the SQL. Then we copy the new generated SQL to a file containing the SQL for our version. Take care of the SQL where tables are changed instead of created, since you must manually alter that table by yourself.
It cannot be done from Symfony afaik.