See this Oracle page.

Oracle has not implemented Unicode as a new string type, but simply as a new encoding, usable with any already existing string and character types.

The default recommended way of using Unicode with Oracle is to use a Varchar2 with an adequate database encoding.

You can create a Unicode database that enables you to store UTF-8 encoded characters as SQL CHAR datatypes (CHAR, VARCHAR2, CLOB, and LONG).

Using the N prefixed types are second option, notably meant for people wanting to transition incrementally to Unicode instead of globally switching to it.

If you prefer to implement Unicode support incrementally or if you need to support multilingual data only in certain columns, then you can store Unicode data in either the UTF-16 or UTF-8 encoding form in SQL NCHAR datatypes (NCHAR, NVARCHAR2, and NCLOB). The SQL NCHAR datatypes are called Unicode datatypes because they are used only for storing Unicode data.

This effectively means Oracle has two Unicode support models. And NHibernate partially implements the one which looks like being the less used:

• When using the hbm2ddl tool, Unicode string properties will be create as N prefixed datatypes column.

• When querying, Unicode string parameters will be sent as Varchar2 datatype.

This causes NHibernate.Test.Linq.ByMethod.GroupByTests.GroupByComputedValueInObjectArrayWithJoinInRightSideOfCase to fail with Oracle with an ORA-12704: character set mismatch error.

We need to give an option for letting the user tell which model he uses. Depending on that option, Unicode string will be mapped toward N prefixed types or not, but for both properties and parameters. By default, I think they should be mapped toward non prefixed types.