I am confused. The way I understand your post is that you want to make even 
harder for the single persistent user people and do nothing for multiple 
persistent unit case?
I think I am misunderstanding your post. 
I think any solution should pass the "it works out of the box" test. 
Consider a scenario that someone adds a second persistent unit into 
persistent.XML file. 
Now all of the sudden everything breaks. 
I think it's such a common problem ( both single and multiple PUs ) that
This should be made braindead simple. 


On Jul 13, 2011, at 5:12 PM, Igor Drobiazko <[email protected]> wrote:

> At a first glance I liked the idea, but the more I think about it the less
> it sounds reasonable to me. Encoding persistence unit name as a sub-package
> provides more confusion than benefits. First of all because it limits you in
> naming your persistence units. As per JPA spec a unit's name is a string.
> So, you are free to use names like "foo-bar" or "1unit" which we would need
> to encode into valid Java package names. This will be confusing.  Another
> objection is that renaming unit name you would need to rename your
> packages.
> 
> I think I'll do it as follows:
> 
> 1) Single persistence unit:
> 
> 1.1) The most of the users will be having only a single persistence unit.
> For such users we need to provide a solution which is compatible with the
> JPA spec. So,we allow autoscanning of the classpath and don't auto-include
> entities from root-package.entities.
> 
> 1.2) For those of us, who loves to place the entities
> into root-package.entities, we could provide a symbol like
> "jpa-compatibility-mode" which is true by default. Having
> jpa-compatibility-mode=true
> results in behavior described in 1.1. If the mode is set to false,
> auto-scanning is switched off and the entities
> from root-package.entities are added automatically.
> 
> 2) Multiple persistence units
> 
> In this case we don't include any of the entities automaticall. The user is
> responsible to add the entities to the entity managers manually as only
> he/she knows which entity belongs to which manager.
> 
> I think this solution provides the lowest confusion rate as the most
> frequent use case just works out of the box.
> 
> On Wed, Jul 13, 2011 at 6:34 PM, Lenny Primak <[email protected]>wrote:
> 
>> After sleeping on this I have an even simpler suggestion. Just auto-scan
>> the .../entities.${persistenceUnit}
>> pah fo it's own entities by default and update package contributor to
>> return a map of PUs to paths so it's easy to customize.
>> 
>> I.e default search path com.xxx.app.entities.PU
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 
> 
> 
> -- 
> Best regards,
> 
> Igor Drobiazko
> http://tapestry5.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to