(I have no idea how it works internally </disclaimer>)
could it be the lockmode setter logic is executed before aliases are
assigned? Also, if the entity is a target per entity (each entity a
different table) subtype, does it work then? (so real aliases are different)
FB
> As Fabio spotted, I've written the 2nd hql query wrong - it should read:
>
> var q = session.CreateQuery("select so from ScheduleOccurrence so,
> ScheduleOccurrence so2 where so.Start = so2.End");
>
> q.SetLockMode("so2", LockMode.Force);
>
> (I've spent so long dealing with the internal ASL for HQL that I'm
> forgetting what the string representation looks like!) Same behaviour with
> the locking though - it throws "{"could not locate alias to apply lock
mode
> : so2"}"
>
> On Wed, Sep 22, 2010 at 11:10 PM, Steve Strong <[email protected]> wrote:
>
>
> Hi Chaps,
>
> Just playing with adding support for LockModes to the Linq provider
> and wanted to get a quick view on it's expected operation. For a simple
HQL
> query such as
>
> var q = session.CreateQuery("select so from ScheduleOccurrence
> so");
> q.SetLockMode("so", LockMode.Force);
>
> I have some corresponding Linq working:
>
> from so in
> session.Query<ScheduleOccurrence>().LockMode(LockMode.Force)
> select so;
>
> I was then starting to look at locking on joins and discovered that
> the following HQL doesn't work:
>
> var q = session.CreateQuery("select so from ScheduleOccurrence so
> from ScheduleOccurrence so2 where so.Start = so2.End");
>
> q.SetLockMode("so2", LockMode.Force);
>
> So the question is, should it? Is this a bug in the HQL parser or
are
> lock modes on additional From clauses not supported?
>
> Cheers,
>
>
> Steve
>
>
