When ever you set a string value in fluent NHibernate it alwasy sets the DB vales to Nvarchar(255), I need to store quite a lot of long string which are based on user inputs and 255 is impractical.
Just to add this is an issue with the automapper as I am using fluent NHibernate to build the database.
Setting the length to anything over 4001 will generate an NVarchar(MAX)...
See here for more detail...
http://serialseb.blogspot.com/2009/01/fluent-nhibernate-and-nvarcharmax.html
Probably you are using "NHibernate validator" as well. If yes, Fluent NHibernate will consider all of the NHibernate validator related data annotations automatically, including string length, not null, etc.
With Fluent Nhibernate Automapper, one quickly realizes that the out-of-the-box behavior for varchar columns is less than ideal. First you discover that every string property was exported as varchar(255) and you need to make a column to be varchar(max). But ideally, you wouldn't have to make every string a varchar(max), right? So you head down that well-trodden path of finding the best way to exert control over the process without breaking out of the various elegant patterns at play...
If you want to have your resulting database varchar columns specified at different lengths, you look to convention classes to make it happen. You might try create name-specific conditions or generally use some naming pattern that you detected inside your convention class.
Neither is ideal. Overloading a name for the purpose of indicating an intended spec in another part of the code is unfortunate- your name should just be a name. Nor should you have to modify convention code every time you need to add or modify a limited-length class property. So how can you write a convention class that gives you control and provides that control in a simple and elegant way?
It'd be sweet if you could just decorate your property like I did for the Body property here:
If this could work, we'd have the control over each string independently, and we'd be able to specify it directly in our entity.
Before I start a maelstrom over separation of database from application, let me point out that this is not specifically a database directive (I made a point of not calling the attribute 'Varchar'). I prefer to characterize this as an augmentation of the System.string, and in my own little universe I'm happy with that. Bottom line, I want a convenience!
To do this, we need to define the decoration we want to use:
Finally, we need to use a string length convention to use the entity's property decoration. This part may not seem pretty, but it does the job, and the good news is that you won't have to look at it again!
StringColumnLengthConvention.cs:
Add this convention to your automapping configuration and there you have it- whenever you want a specific length to result during ExportSchema, now you can just decorate the string property -and only that property- right in your entity!
One of the consistent way that I found is:
in which the VarcharMax and classes are
Adding this convention will set the default length for string properties to 10000. As others have noted, this will be a nvarchar(max) column.
Conventions can be added to an automap configuration like this:
For more information, see Conventions in the Fluent NHibernate wiki.
Hi I came across this Question, with the same problem. I have an slightly safer way of doing it as I don't want all string fields to have 10000 chars by default.
Firstly I register fluent nhibernate with some overrides
My Mapping override class looks like this:
This is only required for small subset of entities with long text values. Maybe some else will find this useful?