> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense? Or does it make more sense to combine them
into
> one contract?
I think the split makes sense, as I understand that there are two different
"phases" of configuration here:
* add multiple sources of configuration (XML files, annotated classes)
* apply further configuration (naming strategy etc.)
Assuming one first needs to configure all the sources before applying the
configuration from the second category, it seems useful to express that in
the API.
The name "MetadataSources" made me stumble a bit, though. Generally I find
pluralized class names a bit odd, only really useful for either
collection-like classes or static helper classes dealing with a specific
type (e.g. Strings, Collections). What would you think about
MetadataSources not being a top-level class itself, but rather an inner
class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
returned by a static creator method on MetadataBuilder:
MetadataBuilder builder = MetadataBuilder.configure() // returns
MetadataBuilderContext
.addFile(...)
.addAnnotatedClass(...)
.addResource(...)
.getBuilder();
IMO that would help users a bit to find the right entry point.
Some more questions/thoughts:
* Who is the intended client for the getter methods on MetadataSources?
Only ORM, or also user code? In case of the former, should the public
MetadataSources
contract be an interface with the addXy() methods only, whereas getters are
only accessible via an internal implementation class? That would narrow
down the exposed API.
* Are MetadataSources#addAttributeConverter(), addAuxiliaryDatabaseObject()
and addSqlFunction() adding a *source* for meta-data really? Somehow it
seems they should rather be located on MetadataBuilder?
* I don't think MetadataSources is intended for concurrent usage from
several threads, right? If so, it should not be needed to have a
ConcurrentHashMap as a member
* MetadataSources#addInputStream() et al.: What schema have passed streams
to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to have
this documented
* MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
modelled with var-args:
sourceTypeProcessingOrder(MetadataSourceType first,
MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
CLASS, HBM );
--Gunnar
2015-03-21 19:09 GMT+01:00 Steve Ebersole <st...@hibernate.org>:
> I had not heard anything back in regards to this, so I wanted to ask one
> more time before I get ready to start cutting 5.0 pre-releases in a week or
> 2.
>
> I'd love to heard feedback of any kind about the new APIs, but specific
> things I know I personally question:
>
> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense? Or does it make more sense to combine them into
> one contract?
>
> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods? E.g.
> MetadataBuilder#with(ImplicitNamingStrategy),
> MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
> MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
> MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)
>
> Also, I am not so sure about the term "with" anymore. I had chosen that at
> the time because I thought it flowed nicely with method chaining.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
