On Wed, 2009-09-16 at 04:30 -0700, greyman wrote: > On Sep 15, 8:56 pm, Travis Duncan <[email protected]> wrote: > > > > Yeah, yeah, we know the drill *points to short story-long stack > > trace*. So, I guess the question is, does DbLinq always become this > > temperamental when it comes to using method calls in where clauses? > > Yes.
I first found out about this issue late last week. I'll be looking into fixing it shortly. > One thing which caught me out when starting out was that you MUST > create a new DataContext object for every query. If you don't and your > app is multi-threaded you'll have issues. Not quite true. You certainly can't share a DataContext instance between threads, AND you should keep the DataContext alive for as short a period as possible, but within those restrictions you can perform more than one query on a DataContext instance. Many of the unit tests do this. > By and large it works pretty well. Recently I've had performance > issues with some operations that need to do a high volume of select > queries. Because the QueryCache doesn't work it means DbLinq is going > to be doing a shed load of work for every select. Yet more proof that we need to get CompiledQuery implemented... - Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" 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/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
