Inline....

On 7 May 2013 19:48, "Max Rydahl Andersen" <notifications@github.com> wrote:
>
> In src/main/java/org/hibernate/forge/generate/GenerateEntitiesPlugin.java:
>
> > @@ -127,8 +128,8 @@ private ReverseEngineeringStrategy
createReverseEngineeringStrategy(
> >  String packageName,
> >  Boolean manyToMany,
> >  Boolean oneToOne,
> > - Boolean optimisticLock) {
> > - ReverseEngineeringStrategy strategy = new
DefaultReverseEngineeringStrategy();
> > + Boolean optimisticLock, String catalogs, String schemas, String
tables) {
> > + ReverseEngineeringStrategy strategy = new
DefaultReverseEngineeringStrategyWithSchemaSelection(catalogs,schemas,tables);
>
> this looks a tad problematic to me.

It actually doesn't seem at all problematic,  since if not specified,  the
defaults actually will be

Catalog=%
Schema=%
Table=%

>
> This means all schemas will be scanned by default no matter what
hibernate tools metadatadialects states.

As I've seen from the code,  this is not true,  as the
DatabaseMetadata.getTables methods are then filtered immediately by these
limitations.

>
> I also means if we at some point add support for passing in reveng.xml or
some other configuration that will be delegating to this default strategy
it will overrule any configuration from there.

I think that this would require a much deeper refactoring of the forge
plugin... probably then you would have to choose between the direct
arguments catalog/schema/table and use only a revenge.xml file...

>
> This strategy should only be enable if the user has explicitly set one of
catalogs, schemas or tables parameters.

This is totally irrelevant,  as if the schema selection is null or the
defaults as defined by this implementation the behaviour inside hibernate
tools code is actually the same...

>
> —
> Reply to this email directly or view it on GitHub.