Not saying the use of platform/environemtn specific url protocols is
bad in any way. Just saying that I think it is unreasonable to code in
Hibernate handling for all these protocols. JBoss VFS, for example, is
much better handled using JBoss VirtualFile API. OSGi protocols will
require very special handling as well, though it *seems* like we may be
able to stick to standard OSGi APIs rather than vendor specific APIs
(but I dont know that for sure yet).
On Sun 17 Mar 2013 03:59:15 PM CDT, Steve Ebersole wrote:
> Not saying the use of platform/environemtn specific url protocols is
> bad in any way. Just saying that I think it is unreasonable to code
> in Hibernate handling for all these protocols. JBoss VFS, for
> example, is much better handled using JBoss VirtualFile API. OSGi
> protocols will require very special handling as well, though it
> *seems* like we may be able to stick to standard OSGi APIs rather than
> vendor specific APIs (but I dont know that for sure yet).
> On Sat 16 Mar 2013 08:29:54 PM CDT, Ales Justin wrote:
>>> I should point out this is based on what we saw when Brett initially
>>> worked with Karaf, especially in the Enterprise OSGi use cases. The
>>> incoming PersistenceUnitInfo contained no urls other than the root
>>> url, which happened to be an osgi bundle url (the protocol was
>>> "bundle"). To me, interpreting all these goofy url schemes is best
>>> left to the environment that defines those schemes. Not much unlike
>>> JBoss AS and its VFS-based urls.
>> Yeah, scanning and funky urls are always a problem.
>> Well, the funky urls are there for a reason -- we can discuss them
>> over beer next time. :-)
>> And in most cases they don't represent a problem,
>> unfortunately resource scanning is not one of those cases.
>> But, imo, any decent framework should account for this,
>> if nothing else, for optimisation reasons.
>> e.g. I pushed a patch to DataNucleus, Spring, Drools, Facelets, ...
>> just b/c of this
>> And Emmanuel and me are the culprits behind initial Scanner. :-)
>> hibernate-dev mailing list
I've been working a bit on HHH-1904  -- truncating identifiers based on a maximum length provided by the Dialect. As an example, a quick test that has a variety of uniques produced the constraint names in .
My initial strategy took metamodel's ObjectName and modified it to automatically handle name segments and quoting. For example, `UK_FooClass_1` would be broken down into "UK", "FooClass", and "1" segments, "_" would be the delimiter, and quoting would be added back in whenever necessary.
I'm trying to find a decent strategy for truncating the name, either as a whole or with each segment. The problem that I keep running into is that it's going to be difficult to dynamically ensure that naming collisions are avoided. For example, if embedded classes are used as entities, you could have 2 constraint names like "UK_OuterClass$InnerClassA_1" and "UK_OuterClass$InnerClassB_1". If the middle segment is truncated at or before the "$", it won't work.
Should we try to enforce a rule that the "unique bits" be in a specific segment or position? Alternatively, "truncate" by hashing the name (as we do with FK names now -- of course, no human readability)? Any other ideas?
Admittedly, I may be overthinking it. It's primarily the Hibernate-generated constraint names that we need to worry about...
Red Hat Software Engineer, Hibernate
What do you think about adding "on-delete" attribute to
"key-many-to-one-element" type in HBM mapping? This would allow
generation of "ON DELETE CASCADE" clause.
Context: "HHH-7807 - Deleting Revision Entity" and "HHH-8052 -
Possibility to deleted audits/revisions in an orderly way".
I'm getting this error when attempting to login to the forums:
It was not possible to convert your password when updating this
bulletin board’s software. Please request a new password. If you
continue to have problems please contact the Board Administrator.
Someone is working on it?
I'm trying to use cascading deletion but it doesn't seem to work.
If you can guarantee that no other object (or row in any other table) holds
a reference to these bids, you can make the deletion transitive.
Hibernate (and JPA) offer a cascading option for this purpose. You can
enable cascading for the delete operation
<set name="bids" inverse="true" cascade="save-update, delete">
Only works for me if I'm mapping to a Set... If I use List it stops working
and returns java.util.ConcurrentModificationException...
<class name="SimpleDatabase" table="TERM">
cascade="save-update, delete, delete-orphan"
<list-index column="FIELD_ORDER" base="1"/>
<class name="SimpleDatabaseOptionalField" table="OPTIONAL_FIELD">
<id name="fieldId" column="FIELD_ID" type="integer">
<property name="termId" column="TERM_ID" type="integer"/>
<property name="fieldOrder" column="FIELD_ORDER" type="integer"
<property name="description" column="DESCRIPTION" type="string"
<property name="xmlPropertyName" column="XML_PROPERTY_NAME"
<property name="rdfPropertyName" column="RDF_PROPERTY_NAME"
Thanks in advance,