Page 1 of 1
Posted: Mon May 10, 2010 2:39 pm
by Malcolm
Anyone doinked around with SQL Server 2008's HierarchyID data type ... specifically for storing trees?
Posted: Mon May 10, 2010 2:52 pm
by TheCatt
No, but I'm intrigued. What are you doing with it?
Posted: Mon May 10, 2010 3:27 pm
by Malcolm
We've got an arbitrary hierarchical tree that's stored in a DB in the standard way -- every row has a column pointing to the ID of the parent row. SQL Server 2008 has this new-fangled HierarchyId data type that's not only supposed to glue the tree together, but provide other bits of useful tree functions (insert, delete, etc.). We're deciding whether to keep the old way or go the new way.
Posted: Tue May 11, 2010 8:05 am
by DoctorChaos
This might be me being cynical, but I would avoid their new fangled toys since it probably won't work the same in the next release. Sorry, feeling a little crusty.
Posted: Wed May 12, 2010 6:10 pm
by Malcolm
Found a way to bullshit hierarchy IDs into playing nice with EF. If you store trees in a DB, this thing seems to be the way to go.
Posted: Thu May 13, 2010 11:47 am
by thibodeaux
Interesting.
Posted: Thu May 13, 2010 2:41 pm
by Malcolm
I spoke a bit too soon. I figured out a way to make EF take the data without problems. The operations are another story...
EF sees the corresponding C# type as untrusted & refuses to run any methods associated with it. It's not that hard to simulate that functionality yourself, though, if you really want to. If you search and return entire subtrees or need to fuck with your tree structurally, it's still the way to go.