Use custom class types in NHibernate with ICompositeUserType

Topics: Core, Customizing Orchard, Troubleshooting, Writing modules
Feb 19, 2013 at 9:40 AM
Seems that there is no way today to do this inside Orchard, only available types are in SchemaUtils.ToDbType ?
If I add my own 'composite type' built using NHibernate ICompositeUserType in migrations.cs:
SchemaBuilder.CreateTable("ProductPriceListPartRecord",
                table => table
                    .ContentPartRecord()
                    .Column<MyOwnType>("MyData")....
I get an exception.
NHibernate.MappingException: property mapping has wrong number of columns
Is there a way to pass this annoying limitation ?
Coordinator
Feb 21, 2013 at 2:36 AM
It's likely that we will have moved to document databases before this is implemented ;) Workaround is to use simple types only and manage some sort of translation back and forth from the part.
Feb 21, 2013 at 7:03 AM
I have beeen using my own OODB engine in 1989 (kind of huge dictionary serializing everything with a global indexer) , then Poet...then RDBMS kids killed the OODB stars.
Seriously it's very limitating when you work with an OOL to have to break every high level though (or thinked so :) ) in basic bricks to store and read.
Feb 21, 2013 at 4:46 PM
Edited Feb 21, 2013 at 9:42 PM
I just see the last comitee meeting video, I understand now why you were speaking about document DB!!!
This is strange to me it seems that the wheel has done a 360°, may be in the 2010s we have more hardware resources and less business concern for this concept coming mature.
In these early times I remember that the problem was in the load command which was trying to load every related thing....Indexing was also a pb.

I do have noticed that in the migrate samples with orchard/yessql.Nhibernate there were still these basic string and int columns....
Coordinator
Feb 22, 2013 at 6:20 AM
Well, I wouldn't say full-circle. The object DBs of the 90s all sucked pretty badly. The technology just wasn't ready. It was a good idea at the time like it is now (which is why it seduced so many people back then), but the implementation wasn't there. It's hard to say what exactly made the approach finally practical but I'd guess that mapreduce was a key innovation. Anyway, doc dbs are now mature enough, and perform a lot better than relational if used correctly and for the right scenarios, which we are pretty sure Orchard is.