property Access strategies in nhibernate - nhibernate

What are the access strategies that I can use in the attribute access of the nhibernate xml?
Can someone point me the possible values to be used in it?
A nice tutorial would be very appreciated.
Thanks

Property Access strategies are described in the reference documentation under 5.1.9. Property.
The access attribute lets you control how NHibernate will access the value of the property at runtime. The value of the access attribute should be text formatted as access-strategy.naming-strategy. The .naming-strategy is not always required.
Access strategy can be one of:
property The default implementation. NHibernate uses the get/set accessors of the property. No naming strategy should be used with this access strategy because the value of the name attribute is the name of the property.
field NHibernate will access the field directly. NHibernate uses the value of the name attribute as the name of the field. If you want the name of the property and not the field to be what the consumers of your API use with HQL, then a naming strategy is needed.
nosetter NHibernate will access the field directly when setting the value and will use the Property when getting the value. A naming strategy is required because NHibernate uses the value of the name attribute as the property name and needs to be told what the name of the field is.
ClassName If NHibernate's built in access strategies are not what is needed for your situation then you can build your own by implementing the interface NHibernate.Property.IPropertyAccessor. The value of the access attribute should be an assembly-qualified name that can be loaded with Activator.CreateInstance(string assemblyQualifiedName).
Naming strategy can be one of:
camelcase The name attribute is converted to camel case to find the field.
camelcase-underscore The name attribute is converted to camel case and prefixed with an underscore to find the field.
lowercase The name attribute is converted to lower case to find the Field.
lowercase-underscore The name attribute is converted to lower case and prefixed with an underscore to find the Field.
pascalcase-underscore The name attribute is prefixed with an underscore to find the field.
pascalcase-m The name attribute is prefixed with the character m to find the field
pascalcase-m-underscore The name attribute is prefixed with the character m and an underscore to find the field.

Related

Assign Component of Class

We all know the ASSIGN COMPONENT name OF STRUCTURE TO <dest> command. I would like to use this command to access public attributes of classes. But according to the documentation (and unfortunately also my debugger), this does not work for classes.
Is there any possiblity to do that? Using classes, it always returns sy-subrc = 4.
Assuming that your reference variable is LR_FOO and the attribute name is BAR, you can use ASSIGN ('LR_FOO->BAR') TO <dest>.

Illegal characters in OrientDB graph for property-type string

I use the graph version of OrientDB. Now I created a schema-less class, where I want to index a variable. This variable needs to become a property first. But when I try to create this property - of type string (or binary, or whatever) - it responds:
com.orientechnologies.orient.core.exception.OSchemaException: The database contains some schema-less data in the property 'clazz.clazz_name' that is not compatible with the type STRING. Fix those records and change the schema again [ONetworkProtocolHttpDb]
So I need to fix something, but what? What characters are illegal for a variable to become a property so that it can be indexed? (BTW, lists are also not an option)
There was indeed a problem I created.
I created a super-class where the property had to be created. One of the sub-classes inserted a List instead of a String. So when querying all vertices of sub-type
final Iterable<Vertex> iterable = this.graph.getVerticesOfClass("clazz");
I printed all types of clazz_name by vertex.getProperty("clazz_name").getClass().getName() where I saw OLinkedList. Reinserting those vertices fixed my problem.

AliasToBean DTO with known type

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

Naming convention for multiword view files in Yii?

If I have a view with two or more words, e.g.:
public function actionApprovalQueue()
what is the naming convention of the view file itself?
approval-queue.php
approvalQueue.php
approvalqueue.php
??
The documentation on Conventions only says:
View files should be named after the view name. For example, the index
view is in the index.php file.
which gives no clue about views with two or more words.
When it comes to naming conventions, it comes down to what suits your organisation, or what is followed in your organisation, or what the rest of your team decides. The key is consistency throughout your code base.
I would say go with the dash(hyphen), because variables are generally named $xyzAbc or $xyz_abc. So it would make sense to use approval-queue.php.
Definitely do not go for approvalqueue.php.
Edit: Read more about Yii's conventions here.
Yii recommends naming variables, functions and class types in camel case which capitalizes the first letter of each word in the name and joins them without spaces. Variable and function names should have their first word all in lower-case, in order to differentiate from class names (e.g. $basePath, runController(), LinkPager). For private class member variables, it is recommended to prefix their names with an underscore character (e.g. $_actionList).
Because namespace is not supported prior to PHP 5.3.0, it is recommended that classes be named in some unique way to avoid name conflict with third-party classes. For this reason, all Yii framework classes are prefixed with letter "C".
A special rule for controller class names is that they must be appended with the word Controller. The controller ID is then defined as the class name with first letter in lower case and the word Controller truncated. For example, the PageController class will have the ID page. This rule makes the application more secure. It also makes the URLs related with controllers a bit cleaner (e.g. /index.php?r=page/index instead of /index.php?r=PageController/index).

NHibernate: why field.camelcase?

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.