So I'm having an Enum-property in an Entity bean:
#Entity
#Table(name = "fileAttachment")
public class FileAttachment
// other properties..
#Enumerated(EnumType.STRING)
FileAttachmentType type;
// getters and setters
However, when I persist the bean, the value in that column is shown as a number such as 0 or 1 or 2.
If I println the value of the enum just before persisting the bean with EntityManager, the value prints out as String, such as INVOICE but in the SQL Server table that row has value 2 for example on the fileAttachmentType-column. What else do I need to configure? I thought the EnumType.STRING would do the trick.
Do you create the table in DB by yourself or rely on Hibernate in it?
If first make sure the column type suits for strings storing.
If second try to use annotation like
#Column(columnDefinition = "enum('VALUE1','VALUE2')")
Ok, in this case things worked out when I added the annotation: #Enumerated(EnumType.STRING)
to the getter of that field and NOT to the actual field.
In another project it works when the annotation is on the field and not anywhere else... so, as far as I comprehed, the answer is the good old "for some reason", but it works now.
If someone would comment the reason for this, I'll update the answer.
EDIT: The reason was found. There was already an annotation on a getter in that Entity class. That's why the annotation on a field didn't work. It happens to be so, that you should either have annotations ONLY on fields OR ONLY on getters. Not annotations on both.
Related
All the examples I am finding for using the AliasToBean transformer use the sessions CreateSqlQuery method rather than the CreateQuery method. They also only return the basic value types, and not any object's of the existing mapped types.
I was hoping it would be possible that my DTO have a property of one of my mapped Domain objects, like below, but I am not getting traction. I get the following exception:
Could not find a setter for property '0' in class 'namespace.DtoClass'
My select looks like the following on my mapped classes (I have confirmed the mappings pull correctly):
SELECT
fcs.MeasurementPoint,
fcs.Form,
fcs.MeasurementPoint.IsUnscheduled as ""IsVisitUnscheduled"",
fcs.MultipleEntryAllowed
FROM FormCollectionSchedule fcs
My end query will be more complex, but I wanted to confirm if this AliasToBean method can return mapped domain objects as well as basic field values from tables retrieved via sql.
the query execution looks like the following:
var result = session.CreateQuery(hqlQuery.ToString())
.SetResultTransformer(NHibernate.Transform.Transformers.AliasToBean(typeof (VisitFormCollectionResult)))
.List<VisitFormCollectionResult>();
note: the VisitFormCollectionResult DTO has more properties, but I wanted to know if I could populate the domain object properties matching the names
update found my problem! I have to explicitly alias each of the fields. once I added an alias, even though the member property on the class matched my DTO's property name, the hydration of the object worked correctly.
The answer to my own question was that each of the individual fields in the select needed an explicit alias matching the property, regardless if the field name already matched the property name of the DTO object:
SELECT
fcs.MeasurementPoint as "MeasurementPoint",
fcs.Form as "Form",
fcs.MeasurementPoint.IsUnscheduled as "IsVisitUnscheduled",
fcs.MultipleEntryAllowed as "MultipleEntryAllowed"
FROM FormCollectionSchedule fcs
Can someone tell me why in NHibernate mapping we can set access="field.camelcase", since we have access="field" and access="property"?
EDIT: my question is "why we can do this", not "what does it mean". I think this can be source of error for developper.
I guess you wonder what use field.camelcase have when we can do the same with just field? That's true, but that would give (NH) properties unintuive names when eg writing queries or reference the property from other mappings.
Let's say you have something you want to map using the field, eg
private string _name;
public string Name { get { return _name; } }
You sure can map the field using "field" but then you would have to write "_name" when eg writing HQL queries.
select a from Foo a where a._name = ...
If you instead using field.camelcase the data, the same query would look like
select a from Foo a where a.Name...
EDIT
I now saw you wrote "field.camelcase" but my answer is about "field.camelcase-underscore". The principles are the same and I guess you get the point ;)
the portion after the '.' is the so called naming strategy, that you should specify when the name you write in the hbm differ from the backing field. In the case of field.camelcase you are allowed to write CustomerName in the hbm, and NHibernate would look for a field with name customerName in the class. The reason for that is NHibernate not forcing you to choose a name convention to be compliant, NH will works with almost any naming convention.
There are cases where the properties are not suitable for NH to set values.
They may
have no setter at all
call validation on the data that is set, which is not used when loading from the database
do some other stuff that is only used when the value is changed by the business logic (eg. set other properties)
convert the value in some way, which would cause NH performing unnecessary updates.
Then you don't want NH to call the property setter. Instead of mapping the field, you still map the property, but tell NH to use the field when reading / writing the value. Roger has a good explanation why mapping the property is a good thing.
I am reading JPA 2.0. I encounter a sentence that
We have used the transient modifier instead of the #Transient annotation so that
if the Employee gets serialized from one VM to another then the translated name
will get reinitialized to correspond to the locale of the new VM.
#Entity
public class Employee {
#Id private int id;
private String name;
private long salary;
transient private String translatedName;
// ...
public String toString() {
if (translatedName == null) {
translatedName = ResourceBundle.getBundle("EmpResources").getString("Employee");
}
return translatedName + ": " + id + " " + name;
}
}
What I understood is that when we use #Entity annotation and container encounter it then it call JPA provider that do the things. Like map id to ID column in database. Although we didn't mention the #Column annotation on the name and salary, but by default it maps to column NAME and SALARY in database. We used transient on translatedName so the JAP leave it as it is, not mapping applied to it. It's just a field in this class. But i am unable to get the understanding of the sentence
if the Employee gets serialized from one VM to another
Someone please explain it to me? Also tell me that what i defined above about the workflow of JAP is correct? Like what happening when container encounter #Entity annotation?
Thanks
When a class implements the java.io.Serializable interface, instances of this class are serializable. That means that the JVM can transform the object into a sequence of bytes. These bytes can be sent over the network, or saved on a disk, and can be read by another VM and transformed back into a Java object.
If a field has the transient Java keyword, it means that this field will be ignored by this serialization mechanism. The field won't be serialized.
A field annotated with #Transient is considered as a non-persistent field by JPA. It won't save it in the database, and it won't load it from the database. But it will be serialized if the object is sent to another JVM.
The Java transient keyword automatically makes a field #Transient. This means that a transient field, won't be serialized, and won't be saved by JPA either.
In the "JEE5 world" you can use detached entities as you would have used transfer objects. (I am not judging whether this is a good idea or not!)
Thus you can call for example a service method (e.g. EJB 3 SLSB method) that returns an instance of Employee remotely with the usual remote-call semantics regarding serialization.
It should be noted, that if an instance of Employee was serialized successfully, then your Java Runtime might be broken, as the class does not implement Serializable.
If you don't want to save the state of your entity arrtibute to DB and also don't want the state to get transferred to another jvm, then use Transient keyword.
If you don't want to save the state of your entity arrtibute to DB, but want the state to be transferred to another jvm, then use #Transient annotation.
How do I query a class of a specific entity in NHibernate?
I basically want a projection that returns a System.Type of each row that matches criteria.
I have looked at Get subclass type from projection with NHibernate however when I create Projections.Property("alias.class") or Projections.Property("class"), I always get could not resolve property 'class'.
Projections.Property("class") is possible and it works, but only if the class has a discriminator.
I got an answer from person on my team (Denis Bykov).
Unfortunately I had hard time making him answer here so I can award him reputation.
I don't think this is possible using NHibernate directly; but consider adding the following to your base entity class (assuming you have one):
protected virtual Type GetTypeUnproxied() {
return GetType();
}
After you have queried your entities, you can interrogate this property to return the actual CLR type of the entity.
If you can't get access to the type through NHibernate for projection purposes, perhaps you can store the System.Type in a field using a custom user type. This should give you the exact functionality you require.
Whilst playing around with an nhibernate mapping, I noticed that a property setter I had was being overloaded (or ignored). This is expected default behaviour with an nhibernate mapping.
So I changed it to use the field.camelCase - so NHibernate would set the private field of the entity class and not the propety getter/setter so I could then use the getter to implement
get { return (new TextInfo()).ToTitleCase(_property);}
I noticed that the output was still what was persisted and this method did not work.
I changed the to _property.ToLower(); and the output was expected as lower case text.
So it appears that there is something I have not done quite right with TextInfo. NHibernate was working correctly (NB NHibernate rocks)
Any ideas why TextInfo is doing this? Probably something trivial I have missed..
For some reason it doesn't work with upper-case strings, uhmmmm Microsoft ;P
Your solution will be to lower case the input first:
get { return (new TextInfo()).ToTitleCase(_property.ToLower());}