Is there a way to take an existing mysql create table String, and turn it into a db_forge array/script suitable for the create_table() method?, ie basically reverse the dbforge process. It is just quicker to make tables in something like Sequel pro, then copy the sql code to the model.
I already have the mysql code, but i was thinking of using the dbforge to allow different databases to be used.
Do people use the dbforge? or just write the SQL creation code manually?
hi if you want to create tables through codeigniter then use migrations class it can solve your problem. you can create, update and delete table with migrations.
CI Migration class
There is no automated process to do what you ask. You have to convert it manually.
I have found that once I became familiar with the dbforge syntax, I can create tables just as quickly, if not quicker, than using Sequel Pro or another SQL GUI.
Related
I am using cakephp 3.
I need to run a script for updating the database schema like adding a column or altering it.
I do not wish to use Migrations as it would require me to write scripts for every change.
Is there any other way to alter schema of the database if we are neither using migrations nor making changes to the database manually using cakePHP 3?
You could use the schema system for doing this, which I think would work fine for things like adding user-defined columns. But if you're looking for an easier way to do migrations, you'd need to put that schema-related code somewhere and keep track of which changes have already been made, and then you're basically just re-inventing migrations.
...or I really need to create a class for each Table? then.. everytime i changes table structure i need to update the code..
You could use an ORM (Object-relational mapper) such as Eloquent, which is included in Laravel, and then just create an model (class) for each table in your database. Eloquent automatically maps each field into a PHP object. If you haven't ever used an ORM, I highly recommend you check out Laravel... it's what made me stick with PHP and I do almost all my projects using Laravel. Best of luck!
Adding to BakerStreet Response.
Eloquent fits your needs as the ORM itself will fetch all the columns you specify if you leave it as default. By default the drivers that it works with are: mysql, postgreSQL, and Sqlite.
Eloquent itself can be downloaded without Laravel being involved.
Please refer to Jeffrey Way's Laracast for instruction:
https://laracasts.com/lessons/how-to-use-eloquent-outside-of-laravel
...thanks all, ended up writting my own magic class:
DBIntrd - Simple PHP framework for SQLite3 databases
Tired of spending time writting a bunch of code to create PHP classes & methods for SQLite tables?
DBIntrd is magic way to dinamically instance objects and persists data at SQLite3 tables..
We have ported the YII Migrations to our application. But sadly due to lack of knowledge / missing req. we are stuck on how to manage migrations between multiple instances of the same database.
Our structure is based on the same database which has different data in it.
While all databases have separate MySQL connection instances and are exactly the same.
The problem we are having is that we need the structural migrations to affect all databases but the data migrations to be applied only to given DB.
Any suggestions how to achieve that?
My idea was that I create an migration instance per database, but I have no means to tell the single migrations apart. I was thinking to use global vars for it, but yuck. Any other ideas?
I have two versions of my blog: the 1st is written in PHP and uses MySQL, but the 2nd, the new one, is written in Python and uses Postgres.
My goal is to move data from one to other. Table names and schema changes.
My idea was to make ORM models for old site, and, using loop, get data using ORM and put it in new database, because I have ORM models for my new site too.
It would look something like:
old_articles = OldArticle.objects.all()
for old_article in old_articles:
new_article = NewArticle()
new_article.title = old_article.name
new_article.content = old_article.body
new_article.save()
ORM would easy abstract differences between the databases and, in my opinion, this could actually work! Or no, are there better ways?
If this migration will only be done once, I wouldn't go the ORM way. Exporting standards-compliant SQL dumps from MySQL is possible and the dumps could easily be imported into PostgreSQL. Once the data is in PostgreSQL, run your migration queries to make the scheme changes or use temporary 'import' tables and copy the data to the tables in the new scheme/lay-out.
Test all your migration queries and write a scenario containing all steps to take, which queries to run and in what order. Also include manual steps that need to be performed.
Once you're sure that the migration scenario is correct, and fully tested, put your old blog in 'maintainance mode' (sorry, we're offline, we'll be back soon) and do it for real!
Most important: test your scenario, validate the result and, take your time, you should never hurry these things!
There are a lot of libraries to do this sort of thing. I would stick to something that is already implemented and well tested. Here is a link to the postgres wiki that has a list of tools to do just this thing.
http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL
The decision I'm trying to make is where I want to do schema changes. I need a schema update to happen in the database, in the model definition, and I'd also like to generate a doctrine migration for that change too. I would really prefer to only have to define schema changes in one place, not three.
Right now I'm thinking of writing all schema changes only as doctrine migrations. I then have a command line tool that runs all pending migrations and does a database->model sync. Is this reliable enough to work? I'm using postgresql if it matters.
The standard flow is to generate an empty doctrine migrations, add the schema changes run the migrations and create your entities. So you'll only need to modify it at 2 places.
This works perfectly with my set-up. Never had any problems with it if you check your down statement at least.