Espigah / dbdeploy

Automatically exported from code.google.com/p/dbdeploy
0 stars 0 forks source link

Support for automagically adding storage clauses, etc #16

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
As a database designer, I want to specify tablespaces and storage for my 
tables and indices, etc, so that my database performs optimally.

* The storage associated with a given object should be able to be varied 
depending on the environment it is being deployed to.  e.g. my development 
server might not have 10Gb of disk space free to allocate to my segment, 
but my prod server absolutely must have this.

Proposal -

There seems to be 2 possible approaches to this:  

1) We could parse the scripts to find create statements and add storage to 
created objects according to some local (environment-specific) 
configuration file.

2) We could use a java DSL to write our create scripts, which would save us 
from having to parse the scripts and would give us much more versatile 
programmatic control.

Either way, an abstract syntax tree would have to be developed to represent 
the DDL, so option 2 might be a useful first step toward option 1.  i.e. 
the DSL would simply be a programmatic way of building our AST by hand, 
with the parser being a way of generating that AST from an existing script.

As with the other DSL enhancement that I have proposed, this could also be 
considered out of scope for core dbdeploy.  Once again, however, there is a 
fair bit of overlap between the two in the script parsing area.

It might be useful to build this as a second module within the dbdeploy 
project?

Original issue reported on code.google.com by akn...@gmail.com on 26 Mar 2009 at 10:41

GoogleCodeExporter commented 9 years ago
This is a genuine problem that many real-life dbdeploy users will have to 
address.

I'm nervous about adding such functionality to dbdeploy core (see notes on issue
#15), certainly not until the core functionality of db works well and issue #10 
is
implemented.

However, I agree that this is something we should try and address, perhaps 
again by
some kind of plugin architecture.

Original comment by gtack...@googlemail.com on 29 Mar 2009 at 11:56

GoogleCodeExporter commented 9 years ago

Original comment by gtack...@googlemail.com on 29 Mar 2009 at 11:56