My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 16: Support for automagically adding storage clauses, etc
2 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----

Blocked on:
issue 10


Sign in to add a comment
 
Reported by akn...@gmail.com, Mar 26, 2009
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?
Mar 29, 2009
Project Member #1 gtack...@googlemail.com
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.
Status: Accepted
Blockedon: 10
Mar 29, 2009
Project Member #2 gtack...@googlemail.com
(No comment was entered for this change.)
Labels: Type-Enhancement
Sign in to add a comment

Powered by Google Project Hosting