Fabio, That's cool. If you're thinking LINQ expressions in the context of NH, you may also want to consider re-linq's QueryModel.ToString(), which prints query expression syntax (from...where...select) instead of the dreaded IQueryable expression tree with all its twisted transformations, nested static methods etc.
OT: I'm surprised to see you're applying the Ms-PL to your project, which is mainly defined by being incompatible with the GPL. With all that Microsoft skepticism you're showing... ;-) Cheers, Stefan From: nhibernate-development@googlegroups.com [mailto:nhibernate-developm...@googlegroups.com] On Behalf Of Fabio Maulo Sent: Monday, June 21, 2010 6:05 PM To: nhibernate-development@googlegroups.com Subject: Re: [nhibernate-development] Re: Linq readonly test overboost I'm converting ExpressionString to string too (in Sharp Tets Ex for the failure message of the satisfier) http://sharptestex.codeplex.com/SourceControl/changeset/view/5f26652fe292#SharpTestsEx%2fSharpTestsEx%2fAssertions%2fExpressionStringBuilder.cs On Mon, Jun 21, 2010 at 12:08 PM, Wenig, Stefan <stefan.we...@rubicon.eu<mailto:stefan.we...@rubicon.eu>> wrote: It's moot then, no problem for me. It's just the way we do things around here, we like it, and I thought you might want to consider that. To give some meaning to all the lurking on your list ;-) (BTW, AST->string should be much easier than the other way round, and it might come in handy for other things too. For instance, in re-linq we render the LINQ ASTs to strings for error messages. Good way to exactly specify the position of an error. But I do understand that's not the only problem you'd face here.) Cheers, Stefan From: nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com> [mailto:nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com>] On Behalf Of Fabio Maulo Sent: Monday, June 21, 2010 2:59 PM To: nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com> Subject: Re: [nhibernate-development] Re: Linq readonly test overboost to complete the phrase: "I think the new test times are quite acceptable" for NH's team needs. If somebody have time to write similar scripts for others RDBMS he can be sure that the new linq-provider work even with the RDBMS he is using at work. As usual: Patchs are welcome ! P.S. Stefan, the translation from string to ANTLR-AST was a PITA, I don't think that the translation from ANTLR-AST to single string is something different than a PITA On Mon, Jun 21, 2010 at 9:37 AM, Steve Strong <srstr...@gmail.com<mailto:srstr...@gmail.com>> wrote: I've no doubt that it would be possible to go down this route, but it won't be quite that simple. Two things that spring to mind would be validation of parameter handling and checking of any client-side projections that are run against the data returned from NH. The first could be done, the second would be trickier since any client-side projections are compiled lambdas so pretty opaque. Of course, you could write separate tests just against those lambdas, passing in-memory data to them to check that they operate correctly,but it would certainly add complexity to the tests. Most of the NH test suite runs against the DB; the issue with the Linq ones was just the way that the data was getting inserted. Now that Fabio's refactored that I think the new test times are quite acceptable. Cheers, Steve On Mon, Jun 21, 2010 at 2:28 PM, Wenig, Stefan <stefan.we...@rubicon.eu<mailto:stefan.we...@rubicon.eu>> wrote: Hi I'm not really following the efforts here, so this might be moot, but here it is: We're testing our re-store LINQ provider by translating LINQ queries to SQL and then comparing actual and expected SQL in the tests. No actual execution against the DB, except in one or two high-level integration tests. You could do the same by emitting the generated HQL AST to an HQL string and just comparing that to the expected HQL. There's not really much use in testing the actual HQL translation from the perspective of a LINQ provider, is there? Stefan From: nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com> [mailto:nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com>] On Behalf Of Steve Strong Sent: Monday, June 21, 2010 11:46 AM To: nhibernate-development@googlegroups.com<mailto:nhibernate-development@googlegroups.com> Subject: Re: [nhibernate-development] Re: Linq readonly test overboost Yeah, sorry about that file - it was built with a code generator, and when I saw how big it was it I knew it had to be sorted out. But other stuff always got in the way so it has lived for far longer than it should have... On Sat, Jun 19, 2010 at 5:05 AM, Ricardo <rs...@usa.com<mailto:rs...@usa.com>> wrote: I did not test the new version of Linq tests, but the function CreateNorthwindData with thousands lines of code seems to make visual studio crawl and consume great amount of memory just to enter the function. I spitted the function in many parts and the code run much faster, 5 times or more. I think you could remove the data from C# code and transfer to a xml file and read the data from a file. On Jun 18, 1:39 am, Fabio Maulo <fabioma...@gmail.com<mailto:fabioma...@gmail.com>> wrote: > Hi all. > I have refactorized the tests of Linq provider to fill DB before the first > fixture and drop it after the last fixture > NUnit > featurehttp://www.nunit.org/index.php?p=setupFixture&r=2.5.5<http://www.nunit.org/index.php?p=setupFixture&r=2.5.5> > > <http://www.nunit.org/index.php?p=setupFixture&r=2.5.5>With NUnit2.5+ > testrunner the old tests crash (confirmed with Richard). > > To run Linq provider integration test for others dialect we have to have 2 > files per dialect: > <dialect-name>LinqReadonlyCreateScript.sql > <dialect-name>DialectLinqReadonlyDropScript.sql > > So far available only for MsSql2008Dialect. > > I'm going to update NUnit of our nhibernate\Tools\nunit to the last version. > > -- > Fabio Maulo -- Fabio Maulo -- Fabio Maulo
