metadata (building) options

gistfile1.java

// Option 1  - Options part of MetadataBuilder which is more "natural" i think, but maybe not 
// feasible if the binding code does know about MetadataBuilder (in which case see option 2).

public interface MetadataBuilder {
    public static interface Options {
        public boolean useNewIdentifierGenerators();
        ...
    }

    ...

    public MetadataBuilder withNewIdentifierGeneratorsEnabled(boolean enabled);

    public Options getMetadataBuilderOptions();
}

public class MetadataBuilderImpl implements MetadataBuilder {
    ...

    private static class OptionsImpl implements Options {
        private boolean useNewIdentifierGenerators; // I believe the default is currently false
        ...

        public boolean useNewIdentifierGenerators() {
            return useNewIdentifierGenerators;
        }
    }

    private final OptionsImpl options = new OptionsImpl();

    public withNewIdentifierGeneratorsEnabled(boolean enabled) {
        this.options.useNewIdentifierGenerators = enabled;
    }

    ...

    public Options getMetadataBuilderOptions() {
        return options;
    }
}


// Option 2  - Options part of Metadata, specifically to make it easier to pass along to binding code afaiu.  
// A pro of this approach is that the options used to construct a Metadata are available from it after it is built.

public interface MetadataBuilder {
    ...

    public MetadataBuilder withNewIdentifierGeneratorsEnabled(boolean enabled);
}

public class MetadataBuilderImpl implements MetadataBuilder {
    ...

    private static class OptionsImpl implements Metadata.Options {
        private boolean useNewIdentifierGenerators; // I believe the default is currently false
        ...

        public boolean useNewIdentifierGenerators() {
            return useNewIdentifierGenerators;
        }
    }


    private final OptionsImpl options = new OptionsImpl();

    public withNewIdentifierGeneratorsEnabled(boolean enabled) {
        this.options.useNewIdentifierGenerators = enabled;
    }

    ...

    public Metadata buildMetadata() {
        return new MetadataImpl( ..., options );
    }
}

public interface Metadata {
    public static interface Options {
        public boolean useNewIdentifierGenerators();
        ...
    }

    public Options getMetadataOptions();
}

I prefer option 1. The binding code should still be able to get a hold of the options via the builder passed into the metadata impl.

I also assume the Options interface would include a buildMetadata() method that would call the like-named method on MetadataBuilder.

No Options would not have a buildMetadata() method. Its purpose is a view of the config options targeting building metadata. Options is simply providing access to these config options.

I did not add withNewIdentifierGeneratorsEnabled() to the interface, just the impl (which I have corrected), so maybe that caused some confusion

Oh, right. You didn't put a return type for the withNew... method, but now I see if that returns the builder, the options wouldn't need the method I mentioned.

I expanded out the second proposal some more.

I think I prefer option 2, but it might help if you add some pseudo client code for the two options.

The client code is the same in either case:

new MetadataSource(...)
        .getMetadataBuilder()
        .withNewIdentifierGeneratorsEnabled( true )
        ...
        .buildMetadata();

Still option 2 :-) I don't think that once Metadata is build there should be any reference to the builder.
How does this tie in with other options? I think we talked about whether we create a setter for all options or only several and have an additional property container for everything else. I guess I am talking about org.hibernate.cfg.Settings.

I'd agree, but that's exactly why I like option 1. Seems like the builder options should be accessed via the builder the user already has a reference to. What use-case might drive wanting to access these options via the Metadata interface? I'm not saying there isn't one; I just don't know what it might be.

You will need these options during the binding phase

There is no defined use case per-se. Just a thought that it might be useful to query the options used to build the metadata. This is all a completely new way to do stuff so a lot of use cases will essentially evolve as we go.

…

On May 18, 2011 8:23 AM, "jpav" < ***@***.***> wrote: I'd agree, but that's exactly why I like option 1. Seems like the builder options should be accessed via the builder the user already has a reference to. What use-case might drive wanting to access these options via the Metadata interface? I'm not saying there isn't one; I just don't know what it might be. ## Reply to this email directly or view it on GitHub: https://gist.github.com/976704

Yes, but that's only in the impl and only during construction time.

Yes internally that is true and the only real defined use case as of now: the process of building the metadata will need access to these options

…

On May 18, 2011 8:40 AM, "hferentschik" < ***@***.***> wrote: You will need these options during the binding phase ## Reply to this email directly or view it on GitHub: https://gist.github.com/976704