Hi, usually DB Engines optimize outer joins if they have enough knowledge about the data structures (means constraints on the database).
Are you working with NOT NULL-constraints and foreign keys? If so: I don't understand why the query is really slower. If not: is it possible for you to add such constraints? On 15 Apr., 07:31, rotgut <[email protected]> wrote: > Hi Fabio, > > what that means is that we are using a very generic Repository pattern > like this for all data access in our system(simplified) > public interface IRepository<T> > { > T Get(int id); > void Save(T); > IQueryable<T> Query; > > } > > This maps to not only databases but also to flat files, xml files, a > few webservices and so forth and allows the developers to use a common > way of querying data in the system. Also the users build dynamic > queries in the system, we then build some expression trees based on > these dynamic queries and use them in the IQueryable part directly. > > We are looking into replacing two existing ORMs(one of them is EF v1 > which has pretty good linq support but absolutely horrible mapping > support and even worse query building performance in special cases) > with nhibernate because of some advanced mapping scenarios to a legacy > database that have recently appeared where only Nhibernate can do the > job as far as we can see. > > And this is why we would hope to use the Linq part and IQueryable<> of > Nhibernate, so we could just plug it in without modifying anything > else in the system. > > On Apr 14, 2:21 pm, Fabio Maulo <[email protected]> wrote: > > > > > > > > > "we are using a repository pattern that relies heavily on IQueryable<> so > > switching from to Criteria or QueryOver is pretty much not an option." > > > What that mean ? > > > For me: > > You have an ORM with at least 4 options to write OO queries. Instead write > > an architecture that allow you the usage of all options you are following > > guide lines of an ORM which have just one option. > > > Question: > > I would know the reason of such decision. > > > Thanks. > > > On Thu, Apr 14, 2011 at 9:12 AM, rotgut <[email protected]> wrote: > > > The interesting thing is that if i use QueryOver<> it also does an > > > inner join. > > > > It should always be inner join when i have mapped references as not > > > nullable, as it is right now it is returning some Properties without a > > > Broker, that wont happen when it is using inner joins. > > > > I would also hate to expand all my linq queries with Broker.Name != > > > null or something like that to get the same output as the criteria/ > > > queryover version and the linq provider still uses a left outer join > > > if i do this "hack". > > > > Inner joins in my current database is much much faster than left outer > > > joins and also we are using a repository pattern that relies heavily > > > on IQueryable<> so switching from to Criteria or QueryOver is pretty > > > much not an option. > > > > Is there any way to force the linq provider to use inner joins? > > > > On Apr 13, 8:50 pm, "Harald M." <[email protected]> wrote: > > > > Oops!!! - I overlooked your addition "Not.Nullable()". It might force > > > > Criteria to optimize the join to an inner, whereas Linq (at this time) > > > > definitely does not do this. > > > > But if the pointer is not nullable anyway, there should not be any > > > > difference between an inner and an outer join - would you agree? So > > > > then there is no bug. > > > > Or is your database highly performance sensitive to outer joins? > > > > Or do you use "dangling pointers" - i.e., the column itself is not- > > > > null, but the target values in the Broker table need not exist? ... > > > > then, I fear, you are at a boundary case of the Linq provider - and > > > > adding that p.Broker != null still might not help (but > > > > p.Broker.BrokerId != null should). > > > > > Regards > > > > Harald > > > > -- > > > 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. > > > -- > > 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.
