I don't think most systems actually put the name Entity into the class
names of business objects.  If you work in a system which uses an ORM
like Hibernate, you just have to deal with these issues.


On 2013-08-01 15:36, David Mason wrote:
> In zanata-model/src/main/java/org/zanata/model/tm/TransMemory.java:
> 
>> +import lombok.Data;
>> +import lombok.EqualsAndHashCode;
>> +import lombok.Setter;
>> +import lombok.ToString;
>> +
>> +/**
>> + * A translation Memory representation.
>> + *
>> + * @author Carlos Munoz <a href="mailto:camunoz@redhat.com">camunoz@redhat.com</a>
>> + */
>> +@Entity
>> +@EqualsAndHashCode(callSuper = true, of = {"description"})
>> +@ToString(exclude = "translationUnits")
>> +@Data
>> +@Access(AccessType.FIELD)
>> +public class TransMemory extends SlugEntityBase implements HasTMMetadata
> 
> I agree that the H is a bit arbitrary and ugly. I don't know that we can
> afford to ignore the fact that our entities are handled by Hibernate
> since we have to ensure they are persisted, and make sure we avoid
> issues with lazy loading. I'm in favour of removing the H, but we'd
> better do it consistently to avoid confusion, and we might want a suffix
> that tells us that a class is an entity so that we know the types of
> issues we need to avoid (e.g. TransMemoryEntity).
> 
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/zanata/zanata-server/pull/78/files#r5522725>.
> 


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat