On Monday, June 2, 2003, at 09:45 AM, Dirk Olmes wrote:
> While I was working on the PostgreSQL Sequence Key generator I thought
> of a
> new structure for
> the PK generation mechanism. I'd like to get rid of DBKeyGenerator
> class
> and put that
> functionality into an extended PKGenerator hierarchy.
I was thinking along the same lines. And I agree with your assessment
that this is beyond 1.0 release, rather we may plan this for 1.1.
> 1) DBEntity holds a reference to the PKGenerator. Unlike now, this
> should
> provide a more
> consistent behaviour: asking a DBEntity for a PKGenerator should never
> return null. If there's
> no PKGenerator configured for a specific entity it returns the
> PKGenerator
> for the adaptor.
> So you'll never have to jump around in hoops just to generate a PK
> and gets
> rid of long
> if-then-else cascades to determine the correct PKGenerator.
Agreed that this should be more consistent. One modification to this
idea though. DbEntity (as all other parts of DataMap) should stay
decoupled from the DataNode and DbAdapter as much as possible. So
returning the right implementation of PKGenerator is something beyond
the scope of DbEntity's responsibilities. The concept of DBKeyGenerator
was right in this respect (though the name is quiet misleading). So
maybe when we start this whole refactoring effort, we should simply
rename it to "PKGeneratorType" or "PKGeneratorStrategy", types being
abstract things like
- "Sequence",
- "Lookup Table",
- "Lookup Table with stored procedure" (current sybase
implementation)
- "In Memory",
- "Autoincrement Column" (if we can figure out how to do this one),
- "Custom class" - an ultimate way to customize the process, etc....
> 2) Refactor the existing classes for Primary Key Generation like:
>
> [PKGenerator <<Interface>>]-------------[AbstractPkGenerator]
> |
> ----------------------
> | |
> [TablePkGenerator]
> [SequencePkGenerator]
> |
> [OracleTablePkGenerator] etc.
+1
Continuing my comment above, each adapter may implement a method
"adapter.getPkGenerator(DbEntity)" that does a lookup of the right
implementation for the chosen strategy, falling back to adapter default
strategy if nothing is configured in DbEntity. This will encapsulate
all the if/else cascades, giving an instance of PkGenerator to whoever
requested it.
> 4) Refactore Modeler to provide a PopUp for the PK generation strategy
> chosen for the
> DBEntity, if nothing is chosen we'll fall back to the strategy that
> comes
> with the adaptor.
+1
The only addition to the modeler compared to its current state will be
a dropdown with strategies; name and cache size will stay there as
well. Or we can do it fancy and customize the panel for each strategy
(change "table name" to "sequence name", etc.). Also in addition to
configuring strategies per DbEntity, we may add the strategy dropdown
to DbAdapter as well.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jun 02 2003 - 22:29:02 EDT