Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate all SQL migration queries #117

Open
piotrooo opened this issue Sep 22, 2013 · 6 comments
Open

Generate all SQL migration queries #117

piotrooo opened this issue Sep 22, 2013 · 6 comments

Comments

@piotrooo
Copy link

I think very good feature will be possibility to generate all migration queries and save for example in file, for example:

php rucus.php db:get_queries > file.sql

Why? I my case I develop some application at linux, but in hosting server I dont have shell and I must run all queries from phpMyAdmin, so when I have file with queries everything will be easier.

@C-Duv
Copy link

C-Duv commented Aug 6, 2014

I would find it useful too.
I'm guessing that creating a Ruckusing_Adapter_Flatfile_Base that extends Ruckusing_Adapter_Interface and writes to a file would do the trick?

This would make ruckusing usable without requiring a live database connection.

@ruckus
Copy link
Owner

ruckus commented Aug 6, 2014

Most of the plumbing is in place. When $conf['log_dir'] is specified than a $ENV.log file is generated which contains all SQL statements sent to the server.

However, this file is formatted with timestamps and contains all queries that also retrieve table information.

You want a log which ONLY contains DML statements (CREATE / DELETE / INSERT / UPDATE, etc) and have those sent to a file w/o any additional formatting, timestamps, etc.

So really the process would involve this:

  1. Create a new config option for "dml_statement_query_log" or something
  2. When running all SQL detect if its a DML statement: send to the dml_statement_query_log

All Adapters currently implement determine_query_type() (which should be added to the Base Adapter) which can be leveraged in #2 to determine if the query should be logged.

If you want to take a stab at this in a PR I would be very thankful.

On Aug 6, 2014, at 1:52 AM, C-Duv [email protected] wrote:

I would find it useful too.
I'm guessing that creating a Ruckusing_Adapter_Flatfile_Base that extends Ruckusing_Adapter_Interface and writes to a file would do the trick?


Reply to this email directly or view it on GitHub.

@C-Duv
Copy link

C-Duv commented Aug 6, 2014

When $conf['log_dir'] is specified than a $ENV.log file is generated which contains all SQL statements sent to the server.

So SQL statements goes to both server and log file?

@ruckus
Copy link
Owner

ruckus commented Aug 6, 2014

As of now, yes, all SQL is logged to the log file.

But since it has other meta-data, such as timestamps and it contains all SELECT operations (e.g. fetching table info, etc) then its not exactly what you need.

On Aug 6, 2014, at 3:15 PM, C-Duv [email protected] wrote:

When $conf['log_dir'] is specified than a $ENV.log file is generated which contains all SQL statements sent to the server.

So SQL statements goes to both server and log file?


Reply to this email directly or view it on GitHub.

@C-Duv
Copy link

C-Duv commented Aug 6, 2014

What I meant was: At current state, if I want to get all queries into a single "flat" file I can set $conf['log_dir'] but:

  • File will contains DML and non-DML SQL statements
  • SQL statements would still be sent to server: thus a live connection to the SQL server is required

You are suggesting to:

  • add an option that define a file location where to write DML statements
  • declare determine_query_type() into Ruckusing_Adapter_Base (already present in implemented Ruckusing_Adapter_*_Base)
  • Modify Ruckusing_Adapter_*_Base::query() so that it writes DML to that DML-only file.

I was more like: create a new Ruckusing_Adapter_Base (say Ruckusing_Adapter_Flatfile_Base) whose dsn is an array containing the file location.

But for the solution to be "offline" (no live connection to SQL server) we need a way to tell ruckusing the schema version starting point (since it cannot ask the server for that) when asking for SQL change statements (and default to version "0") right?

I'm just discovering ruckusing but once I've played with it a bit I can file a PR to answer this issue.

@ruckus
Copy link
Owner

ruckus commented Aug 6, 2014

Yes, you got it.

I think trying to jigger it all around to work against a non-live server will be way too complex and outside the scope. Basically the whole framework queries the server to get all sorts of meta info about the tables / columns / indexes, etc.

So I stand by my original suggestion - which you have encapsulated below.

Thanks in advance for your contributions!

On Aug 6, 2014, at 4:00 PM, C-Duv [email protected] wrote:

What I meant was: At current state, if I want to get all queries into a single "flat" file I can set $conf['log_dir'] but:

File will contains DML and non-DML SQL statements
SQL statements would still be sent to server: thus a live connection to the SQL server is required
You are suggesting to:

add an option that define a file location where to write DML statements
declare determine_query_type() into Ruckusing_Adapter_Base (already present in implemented Ruckusing_Adapter___Base)
Modify Ruckusing_Adapter___Base::query() so that it writes DML to that DML-only file.
I was more like: create a new Ruckusing_Adapter_Base (say Ruckusing_Adapter_Flatfile_Base) whose dsn is an array containing the file location.

But for the solution to be "offline" (no live connection to SQL server) we need a way to tell ruckusing the schema version starting point (since it cannot ask the server for that) when asking for SQL change statements (and default to version "0") right?

I'm just discovering ruckusing but once I've played with it a bit I can file a PR to answer this issue.


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants