[NHibernate] Comportamento estranho Stored Procedure

[Rui Santos]

No decurso das experiências com NHibernate deparei-me com um comportamento no mínimo estranho.

Contextualizando o problema. Necessitava de agregar informação de várias tabelas e fazer algumas transformações entre as quais o equivalente a uma pivot table do excel.Pareceu-me que o mais eficiente para este caso seria uma Stored Procedure. 

Por isso criei uma classe e um mapeamento hbm (sem tabela física associada), e uma named query para popular a classe com os dados vindos da sp. Até aqui tudo bem.

O problema vem a seguir, quando a sp retorna os dados e faz o transaction.commit tenta também fazer update aos dados na tabela. Como a classe não tem nenhuma tabela física associada, dá erro.

  ICollection<Data> data = null;

  using (ISession session = NHelper.OpenSession())

  {

     using (ITransaction transaction = session.BeginTransaction())

                {

                    data = session.GetNamedQuery("SP")

                        .SetInt32(0, valor).List<Data>();

                    transaction.Commit();

       }

   }

   return data;

A primeira questão que se põe é, porque motivo tenta fazer update na bd, quando faz o transaction.commit?

No entanto se tirar a transaction já não tenta fazer o update.

Portanto a segunda pergunta é como é que o transaction do nhibernate funciona, para provocar este comportamento?

  ICollection<Data> data = null;

  using (ISession session = NHelper.OpenSession())

  {

             data = session.GetNamedQuery("SP")

                        .SetInt32(0, valor).List<Data>();

   }

   return data;

[Pedro Sousa]

Já tive um problema análogo de Updates em Reads.

Esta página explica bem o problema que eu tive, mas não sei se se aplica ao teu caso (visto ser um SP com uma named query).

Seja como for aqui fica a referência, e pode ser que ajude:

http://zvolkov.com/blog/post/2009/07/09/Why-NHibernate-updates-DB-on-commit-of-read-only-transaction.aspx

2010/8/30 Rui Santos <san...@gmail.com>

--
Pedro Sousa

[Ricardo Peres]

Rui,

Manda as classes e o mapeamento, sff.
Parece um problema de ghost properties: a ISession pensa que o objecto
foi modificado.
Podes confirmar isso com session.IsDirty() e com o método seguinte:

public static Boolean IsDirtyEntity(this ISession session, Object
entity)
{
if (session == null)
{
throw new ArgumentNullException("session");
}

String className =
NHibernateProxyHelper.GuessClass(entity).FullName;
ISessionImplementor sessionImpl =
session.GetSessionImplementation();
IEntityPersister persister =
sessionImpl.Factory.GetEntityPersister(className);
EntityEntry oldEntry =
sessionImpl.PersistenceContext.GetEntry(sessionImpl.PersistenceContext.Unproxy(entity));
Object [] oldState = oldEntry.LoadedState;
Object [] currentState = persister.GetPropertyValues(entity,
sessionImpl.EntityMode);
Int32 [] dirtyProps = persister.FindDirty(currentState, oldState,
entity, sessionImpl);

return (dirtyProps != null);

}


On Aug 30, 7:47 pm, Pedro Sousa <pedro.sou...@gmail.com> wrote:
> Já tive um problema análogo de Updates em Reads.
>
> Esta página explica bem o problema que eu tive, mas não sei se se aplica ao
> teu caso (visto ser um SP com uma named query).
>
> Seja como for aqui fica a referência, e pode ser que ajude:
>

> http://zvolkov.com/blog/post/2009/07/09/Why-NHibernate-updates-DB-on-...
>
> <http://zvolkov.com/blog/post/2009/07/09/Why-NHibernate-updates-DB-on-...>

[Rui Santos]

Muito obrigado, 

Infelizmente não me é possível enviar as classes e mapeamento por imposições de segurança da empresa.

No entanto, efectivamente a classe estava "Dirty" e o problema tem a ver com a diferença entre os campos que são nullable na base de dados e na classe NHibernate. Nada que não fosse resolvido com o '?' maravilha.

Mais uma vez obrigado pela vossa preciosa ajuda.

2010/8/30 Ricardo Peres <rjp...@gmail.com>

--
http://forum.velaligeira.com