Comments on: A simple task to generate sql scripts

By: cakebaker

cakebaker — Fri, 04 Sep 2009 14:28:01 +0000

@Matt: You are welcome!

By: Matt Kaufman

Matt Kaufman — Thu, 03 Sep 2009 02:21:37 +0000

Thanks for this genius script…. This is the most useful thing for SQL in the world! :)

Haven’t seen anyone do anything this simple and awesome for this. great thinking / solution.

By: cakebaker

cakebaker — Wed, 04 Jul 2007 06:40:05 +0000

@Bryn: Cool to hear that :)

By: Bryn

Bryn — Tue, 03 Jul 2007 18:14:27 +0000

Thanks it works great! (sorry about the double post previously)

By: cakebaker

cakebaker — Thu, 21 Jun 2007 12:45:00 +0000

@Bryn: I uploaded a new version to the downloads section. It is no longer a bake task but a cake shell script. The usage is now

cake sqlscripts table1 table2...

By: Bryn

Bryn — Wed, 20 Jun 2007 16:09:09 +0000

Anybody have any tips on how to make this work with Cake 1.2?

By: bryn

bryn — Wed, 20 Jun 2007 16:07:45 +0000

Anybody have any suggestions on how to make this work with Cake 1.2?

By: cakebaker

cakebaker — Mon, 30 Oct 2006 16:57:23 +0000

@Dieter@be: Yeah, keep your “all-DDL-in-php” idea, experiment with it, and build a cool solution ;-)

By: Dieter@be

Dieter@be — Sun, 29 Oct 2006 15:37:52 +0000

Well, you have some good points, if the task is intented to do just that, keeping the sql DDL in sync with the php cake models is just a small sacrifice for the dev. (no matter the solution, there is always a small sacrifice/compromise the dev has to make) I’m not going to forget my “all-DDL-in-php idea though ;-)

On the other hand, it would be nice to have a task that is able to import/export the complete contents of a database.. By the time i start to use cake 1.2 i will maybe edit your script to give it the extra functionality. (if nobody did it before me) :-)

Dieter

By: cakebaker

cakebaker — Sun, 29 Oct 2006 08:53:37 +0000

@Dieter@be: Thanks for your comment.

First a correction: The task is useless in the scenario you described (sql export of dev environment and import in production environment). It is intended to be used for creating the skeleton of the table creation script for the dev environment.

I am not sure if there should be some abstract level from which the database is generated. The only advantage of such an abstract level I see at the moment is when you want to support different databases. But I think most applications are built for just one database. So I think it is not worth the additional complexity.

And concerning the workflow: for me it is more logical to start at the bottom layer and to move upwards, than to start on a middle layer and to create the bottom layer. If I start on a middle layer I am either restricted in what is possible (I possibly can’t use a nice feature specific to a database) or the middle layer is much more complex as it contains the complexity of both layers.