Should save or merge generate sql if the session is not flushed?

[gusgorman]

Hello,

Just looking for some clarification on how I should expect nhibernate
to behave.

Should save or merge generate an insert statement if the session is
not flushed? (ie in a transaction where the FlushMode is set to Never
and you also don't explicitly flush the session).

I realise that it would have to if you were using a sql server
identity column (because it needs to go straight to the database to
get it). However, I assumed it wouldn't if you were using a different
type of primary key such as an assigned GUID?

cheers,
Jordan.

[Dietrich]

I would advise (if you don't have it) getting NH Profiler and running that to investigate what NHibernate is doing with your SQL server. 

I have always noticed merge, save, and delete running the sql statement on call. If you call them within the scope of a transaction, however, you can always roll back the transaction to negate the changes.

[gusgorman]

Hi Dietrich,

Thanks for the reply

> I would advise (if you don't have it) getting NH Profiler and running that
> to investigate what NHibernate is doing with your SQL server.

I have seen it generating the insert when I call merge in this
scenario, however I would not expect it to. Thats why I was looking
for some clarification. I want to make sure I'm not trying to do
something that (according to nhibernate's design) is not possible.

> I have always noticed merge, save, and delete running the sql statement on
> call. If you call them within the scope of a transaction, however, you can
> always roll back the transaction to negate the changes.

Good point, but in this case I don't really want to roll back the
transaction, just merge an object with the current session.

regards,
Jordan.

[gusgorman]

Hi Dietrich,

Thanks for the reply - I replied last Friday but it seems to have
disappeared into the mists of the internet.

> I have always noticed merge, save, and delete running the sql statement on
> call. If you call them within the scope of a transaction, however, you can
> always roll back the transaction to negate the changes.

Well that it what I am seeing here too (insert generated when I call
merge). I really wouldn't expect it to though because the flush mode
is 'Never.'

In this case I do not want to roll back the transaction - I am
building up a domain object over multiple web requests and want to re-
associate it with the current session so that I can rely on lazy
loading.

The ideal solution here would probably be to switch to some sort of
session-per-conversation pattern but I simply do not have the time to
change the architecture.

regards,
Jordan.

[Dietrich]

Are you using Database Generated ID's such as an Identity column? 

[gusgorman]

No, I am not. I'm used GUIDs (which I assign myself in the constructor
of the object)

[John Davidson]

See

http://stackoverflow.com/questions/170962/nhibernate-difference-between-session-merge-and-session-saveorupdate

for a description of what merge does. In some cases an insert would be a valid action as part of a merge.

John Davidson

--
You received this message because you are subscribed to the Google Groups "nhusers" group.

To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[gusgorman]

Hi John,

Thanks for the reply.

Yes I release that in some cases an insert would be a valid action as
part of a merge - but what I am getting at is that I wouldn't expect
the sql to be generated if the session is not flushed (ie flush mode
is set to never and session.Flush() is not called explicitly).

Jordan.


On Jul 18, 5:08 pm, John Davidson <jwdavid...@gmail.com> wrote:
> See
>
> http://stackoverflow.com/questions/170962/nhibernate-difference-betwe...

>
> for a description of what merge does. In some cases an insert would be a
> valid action as part of a merge.
>
> John Davidson
>

[John Davidson]

I think that merge has an implied flush that happens if it is required, i.e. if there is an insert condition - it is necessary to assigned the object id and validate that it stored correctly

John Davidson

[gusgorman]

Ah - missed this reply.

Right. That explains what I am seeing. hmm - Fair enough. (I thought
it would only go to the database if the primary key was an identity
column.)

To be honest I haven't actually found the time to right any tests that
confirm the exact behaviour. I ended up just changing the code that
depended on it.

regards,
Jordan.