Here's an example:
We are in a three tier architecture. There is an entity with an
"availability" property. Changing it means some extra work on the
server side. When the entity is passed to the StoreMyEntity method on
the server, we need to find out if it changed or not.
// =========================================================
// Pseudo code (as it could look like)
// =========================================================
StoreMyEntity(entity)
{
originalState = dal.GetOriginalState(entity)
if (originalState.Available != entity.Available)
{
// Do special work
}
dal.SaveOrUpdate(entity)
dal.Commit()
}
This is a simple example and could be solved with Merge or Evict. Here
are more examples to demonstrate what Merge or Evict means in slightly
more complex cases:
// =========================================================
// using Evict, server logic split in several methods:
// =========================================================
StoreMyEntity(entity)
{
DoSomeStuff(entity);
DoSomeMore(entity);
}
DoSomeMore(entity)
{
// be sure it is not in the cache from previous operations
// ugh !!
dal.Evict(entity)
original = dal.Get(entity.id);
if (original.Available != entity.Available)
{
// do special work
}
// remove the old value from the cache again
// to make store possible, ugh again
dal.Evict(entity)
}
// =========================================================
// using Merge, complex entity structure:
// =========================================================
StoreMyParent(parentEntity)
{
// compare a value of a child entity
originalChildState = dal.Get(parentEntity.Child.id)
if (originalChildState.Available != parentEntity.Child.Available)
{
// do special work
}
// now the ugly part: we have to change the
// actual object structure to be able to store it!
parentEntity.Child = dal.Merge(parentEntity.Child)
dal.SaveOrUpdate(parentEntity)
dal.Commit();
}
On 27 Nov., 15:16, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> Ok understand.... it need an example.
>
> 2008/11/27 Stefan Steinegger <[EMAIL PROTECTED]>
>
>
>
>
>
> > I don't understand this. "Child" is a weak word, because it is used
> > for everything. With sessions, I think it means: the "child" gets the
> > connection and transaction of the "parent" and - most important -
> > shares its lifecycle. It's not at all about inheritance. Say "master
> > and slave" and choose if the dog is the master of the cat or vise
> > versa :-)
>
> > Back to the original problem I actually want to solve: I want to get
> > values directly from the database (ignoring the cache), just for one
> > or two queries, not the whole session's scope.
>
> > Another solution:
> > ISession.GetDatabaseSnapshot<T>(object id)
>
> > This gets the database state of an entity. Advantage: Explicit name,
> > no other session. Disadvantage: you can't make a query to get several
> > instances. It would be nice to have the whole NH query API. So we
> > either duplicate the whole query related API (the worst of all
> > solutions), use a property that switches to stateless and implements
> > IStatelessSession (my first solution) or we create a child session
> > that is stateless. Or - I don't know anything else.
>
> > On 27 Nov., 14:04, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> > > My dog can't be a child of my cat ;)
>
> > > 2008/11/27 Stefan Steinegger <[EMAIL PROTECTED]>
>
> > > > Why is "my" stateless session not a child session?
>
> > > > On 27 Nov., 12:54, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> > > > > But are two different things and, if I well remember, child statefull
> > > > > session are not completely supported (at least not full tested).A
> > session
> > > > > may be a "factory" of child sessions but would be strange to see a
> > > > session
> > > > > as a factory of a "no-child-stateless-session"...
> > > > > may be only a semantic matter.
>
> > > > > 2008/11/27 Stefan Steinegger <[EMAIL PROTECTED]>
>
> > > > > > I think you misunderstood. It's not "transform", it creates another
> > > > > > stateless session that shares the same transaction. There is
> > actually
> > > > > > already a ISession.GetSession() method, it creates another session
> > > > > > sharing the transaction AND cache.
>
> > > > > > Probably it should be called ISession.GetStatlessSession()
>
> > > > > > If you would use the session factory, you would have to write
> > > > > > sessionfactory.OpenStatelessSession(oldsession.Connection)
> > > > > > what's really bad and shouldn't be recommended.
>
> > > > > > On 27 Nov., 12:25, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> > > > > > > 2008/11/27 Stefan Steinegger <[EMAIL PROTECTED]>
>
> > > > > > > > What about a practical syntax like
> > > > ISession.Stateless.CreateCriteria
> > > > > > > > (...)?
>
> > > > > > > mmmm... I don't like it.The SessionFactory is the factory of
> > session
> > > > and
> > > > > > a
> > > > > > > stateFull session can't be transformed in a stateless
> > > > > > > ISession.Stateless is ambiguous
> > > > > > > --
> > > > > > > Fabio Maulo
>
> > > > > --
> > > > > Fabio Maulo
>
> > > --
> > > Fabio Maulo
>
> --
> Fabio Maulo
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
