-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: Replacement example for EJ3BNamingStrategy
PostPosted: Sun Apr 24, 2016 8:42 pm 
Newbie

Joined: Fri Sep 03, 2010 6:27 pm
Posts: 8
Location: Munich
In Hibernate 5, NamingStartegy has been removed, i.e. EJ3BNamingStrategy is not available any more.
I use a custom naming strategy based on EJ3BNamingStrategy which worked just fine.
I've overridden collectionTableName with

Code:
    public String collectionTableName(
            String ownerEntity, String ownerEntityTable, String associatedEntity,
            String associatedEntityTable,
            String propertyName) {
        return PREFIX + super.collectionTableName(ownerEntity, ownerEntityTable,
                associatedEntity, associatedEntityTable, propertyName).toLowerCase();
    }


and cannot find any working equivalent for Hibernate 5.
Can anyone point me in the right direction?


Top
 Profile  
 
 Post subject: Re: Replacement example for EJ3BNamingStrategy
PostPosted: Mon Apr 25, 2016 9:22 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
Checkout ImplicitNamingStrategy.html#determineCollectionTableName.

Depending on your naming strategy requirements, you can extend one of the following implementations, and override the `determineCollectionTableName` method:

  • ImplicitNamingStrategyComponentPathImpl
  • ImplicitNamingStrategyJpaCompliantImpl
  • ImplicitNamingStrategyLegacyHbmImpl
  • ImplicitNamingStrategyLegacyJpaImpl


Top
 Profile  
 
 Post subject: Re: Replacement example for EJ3BNamingStrategy
PostPosted: Mon Apr 25, 2016 3:09 pm 
Newbie

Joined: Fri Sep 03, 2010 6:27 pm
Posts: 8
Location: Munich
Thanks for the answer.
However, that's how far I have got myself. Problem is that each of the implementations I tried to adapt runs into one problem or another. I'll keep trying.
I had hoped for a hint which of the available naming strategies comes next to the EJB3NamingStrategy which has never been deprecated but simply given up because the NamingStrategy has been split into two new interfaces which are totally incompatible with their predesessor.
I don't want to complain too much because I really appreciate the hard work of so many people providing a great piece of software.
However, over the exitement over new features and code improvements there should be more awareness that each change of interfaces which is not backward compatible breaks existing applications and sometimes precludes updating to a new version.

Off topic: I give you another example.
Transaction#isActive() has been removed and replaced by getStatus() which returns e.g.TransactionStatus.ACTIVE. I admit that this looks cleaner in the status context but why could the 'old' method not simply be kept as a convenience method?


Top
 Profile  
 
 Post subject: Re: Replacement example for EJ3BNamingStrategy
PostPosted: Tue Apr 26, 2016 1:38 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
I know what you mean. For the naming strategy, the change happened to align the mapping to JPA requirements. As for Transaction#isActive(), you are right. That would have caused fewer issues on the client-side.

Some changes need to happen because otherwise the project would be stuck. Usually, this kind of changes only happen when you migrate from one major version to the other: 4.x -> 5.x, in which case you need to use the migration guide to get to understand what needs to be changed on the application side as well.


Top
 Profile  
 
 Post subject: Re: Replacement example for EJ3BNamingStrategy
PostPosted: Tue Apr 26, 2016 5:12 am 
Newbie

Joined: Fri Sep 03, 2010 6:27 pm
Posts: 8
Location: Munich
I appreciate your answer. The sad story is, that sometimes release notes appear to be far from complete.

News: I finally found a solution. At least it works for my use case.
The key to the working solution was to also override determineJoinColumnName
Maybe the code is useful to folks having similar problems.

Code:
//    POSper is a Point of Sale System.
//    Copyright (C) 2007 OXN Technologies
//    Copyright (C) 2016 arcasys
//    www.posper.org
//
//    This program is free software; you can redistribute it and/or modify
//    it under the terms of the GNU General Public License as published by
//    the Free Software Foundation; either version 2 of the License, or
//    (at your option) any later version.
//
//    This program is distributed in the hope that it will be useful,
//    but WITHOUT ANY WARRANTY; without even the implied warranty of
//    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
//    GNU General Public License for more details.
//
//    You should have received a copy of the GNU General Public License
//    along with this program; if not, write to the Free Software
//    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

package org.posper.hibernate;

import org.hibernate.boot.model.naming.EntityNaming;
import org.hibernate.boot.model.naming.Identifier;
import org.hibernate.boot.model.naming.ImplicitJoinColumnNameSource;
import org.hibernate.boot.model.naming.ImplicitJoinTableNameSource;
import org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl;

/**
* @author Hans <mail@arcasys.de>
*
*/
public class PosperNamingStrategy extends ImplicitNamingStrategyLegacyJpaImpl {

    private static final long serialVersionUID = -6156051787915506283L;
    private static final String PREFIX = "posper_";

    @Override
    protected String transformEntityName(EntityNaming entityNaming) {
        return PREFIX + entityNaming.getJpaEntityName().toLowerCase();
    }

    @Override
    public Identifier determineJoinTableName(ImplicitJoinTableNameSource source) {
        String tname = (PREFIX +
                source.getOwningEntityNaming().getJpaEntityName() + "_" +
                source.getNonOwningEntityNaming().getJpaEntityName()).toLowerCase();
        System.out.println("0: " + tname);
        return Identifier.toIdentifier(tname);
    }
   
    @Override
       public Identifier determineJoinColumnName(ImplicitJoinColumnNameSource source) {
      final String name;
      if ( source.getNature() == ImplicitJoinColumnNameSource.Nature.ELEMENT_COLLECTION
            || source.getAttributePath() == null ) {
                        // This is the relevant change to avoid that the join column name is also prefixed
                        // which happened for ManyToMany associations
         name = source.getEntityNaming().getJpaEntityName().toLowerCase()
               + '_'
               + source.getReferencedColumnName().getText();
      }
      else {
         name = transformAttributePath( source.getAttributePath() )
               + '_'
               + source.getReferencedColumnName().getText();
      }

      return toIdentifier( name, source.getBuildingContext() );
   }
    }


Top
 Profile  
 
 Post subject: Re: Replacement example for EJ3BNamingStrategy
PostPosted: Tue Apr 26, 2016 5:15 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
Thanks for posting a solution. You can open a JIRA issue to suggest a fix for the migration guide too.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.