var user = session.Load<User>(id);
var root = session
.CreateQuery("from Node n where n.User
= :user and n.IsRoot = true")
.SetEntity("user", user)
.SetMaxResult(1)
.FutureValue<Node>();
session
.CreateQuery("from Node n where n.User
= :user and n.IsRoot = false")
.SetEntity("user", user)
.Future<Node>();
return Mapper.Map<Node, DtoTreeDto>(root.Value);
--- or ---
var user = session.Load<User>(id);
var nodes = session
.CreateQuery("from Node n where n.User
= :user")
.SetEntity("user", user)
.Future<Node>();
var tree = BuildTreeFrom(nodes);
return Mapper.Map<Tree, DtoTreeDto>(tree);
--- or ---
var user = session
.CreateQuery("from User where id = :id")
.SetParameter("id", id)
.FutureValue<User>();
var nodes = session
.CreateQuery("from Node")
.Future<Node>();
var tree = BuildTreeFrom(nodes);
var trimmedTree = tree.For(user.Value)
return Mapper.Map<Tree, DtoTreeDto>(trimmedTree);
These are just some options.
On Nov 11, 2:31 pm, Scott <[email protected]> wrote:
> I don't understand what you mean in option 1 by "the tree will be
> built directly from the query"
> Are you saying if I do something like write a Linq query that returns
> all the Standards the user has access to NHibernate will automatically
> assemble them into the tree? I was under the impression if I did that
> then I would have to assemble the tree in my code.
>
> On Nov 11, 1:18 pm, Jason Meckley <[email protected]> wrote:
>
> > efficiently resolving trees is a common issue. search the groups and
> > you will find hundreds of posts. Factors that influence an optimal
> > approach include
> > 1. the size of the tree
> > 2. the depth of the tree
> > 3. how the user interacts with the tree
>
> > option 1
> > query only the standards the user can access. instead of resolving the
> > entire tree, only resolve nodes the user has access to. the tree will
> > be built directly from the query.
>
> > option 2
> > store the nodes in the database, but build the tree outside the scope
> > of NH. You can then build and modify the tree however the context
> > requires, you don't have to worry about affecting the database.
>
> > in either case, I would not transmit the domain objects beyond the
> > domain (physical or logical). I would convert the object to a context
> > specific DTO and send this outside the domain.
>
> > I had a similar situation recently. my tree was simple. there were
> > parents and children.
> > root
> > parent A
> > child 1
> > child 2
> > parent B
> > child 3
>
> > there is the main "unchanging" tree. the user had access to specific
> > nodes on the main tree. I would resolve the main tree, the user and
> > the user's accessible nodes. I then iterated over the main tree and if
> > the user could access the node i returned the node. after I had all
> > the nodes I built a DTO representing the specific information I
> > needed. In this case I needed the id and name of each node to display
> > to the user. In another view a i needed the id, name and calculated
> > date. this meant another DTO.
>
> > The DTO was passed to the UI and rendered so the user could see the
> > information.
>
> > On Nov 11, 1:53 pm, Scott <[email protected]> wrote:
>
> > > Ok, here's basically what I have, if it isn't enough information then
> > > maybe you can just give me one or two quick suggestions.
>
> > > I have a self referencing parent/child tree, 1 object, Standard, which
> > > contains a collection of other Standards, this builds a tree of them.
> > > The Standards have various attributes on them and depending on a
> > > user's security level they may only be allowed to access one with
> > > attribute x but not y. I serialize the tree of Standards a user has
> > > access to and pass it over to some other code. So I was just getting
> > > the complete tree and crawling through it pruning the branches that
> > > aren't allowed but this act of pruning gets pushed into the database.
>
> > > On Nov 11, 12:40 pm, Jason Meckley <[email protected]> wrote:
>
> > > > there isn't enough information to make a recommendation.
>
> > > > On Nov 11, 12:58 pm, Scott <[email protected]> wrote:
>
> > > > > So then what's the best way of filtering down collections determined
> > > > > by individual users while maintaining the object tree?
>
> > > > > Do I have a collection in the object that I put "accessible" objects
> > > > > into instead of modifying the one NHibernate uses?
>
> > > > > On Nov 11, 11:38 am, Jason Meckley <[email protected]> wrote:
>
> > > > > > you did tell NH to make them determinant. Changing the state of
> > > > > > entities associate with the session informs NH to change the state
> > > > > > of
> > > > > > the database. The point of NH is to allow you write code without
> > > > > > thinking (too much) about how/when/why data is persisted.
>
> > > > > > If you want to make "non permanent" changes you will need to
> > > > > > disassociate the objects from NH. this could be done by
> > > > > > disconnecting
> > > > > > from session, or loading the necessary data into DTOs.
>
> > > > > > * side note: SaveOrUpdate() is there only for edge cases. It should
> > > > > > not be required in common usage. Even the explicit usage of save
> > > > > > and
> > > > > > delete can be minimized. You can focus on solving the business
> > > > > > problem. NH will handle your database requirements.
>
> > > > > > On Nov 11, 12:15 pm, Scott <[email protected]> wrote:
>
> > > > > > > I start a transaction and I modify some collections based on user
> > > > > > > security. I have no intention of making these changes permanent,
> > > > > > > just
> > > > > > > in the context of the user they're not allowed access to those
> > > > > > > items.
> > > > > > > I never do a SaveOrUpdate() on the object with the collection or
> > > > > > > any
> > > > > > > of the items in it. Basically I'm expecting only 1 insert to
> > > > > > > happen in
> > > > > > > this transaction but since I modified those collections when I
> > > > > > > commit
> > > > > > > the transaction those changes get pushed into the database.
>
> > > > > > > Why is NHibernate updating records that I never told it to make
> > > > > > > permanent?
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
