OK, I apparently misunderstood a lot of your arguments.
Regarding the "internal names" I'm talking about, these are the aliases
given to tables or columns in the request. Some internal names may also be
use for special operations, like Skip() and Take() on Oracle, for example.
Also, the formatting may change, to be more readable or smaller, depending
on what the application wants.
Also, this is not just names, but some comments may be added. I had the
concrete case last year where we wanted to identify which linq request was
generated a specific SQL expression. This is not possible with MS Linq to
SQL, but in DbLinq (extended mode), we may add some event handlers to allow
the user to add some information directly in the generated SQL.
So this brings us to regular expressions: I know they are hard to maintain
(because hard to read), so we could imagine an intermediate string format
that would generate a Regex from it, without the hassle of writing regular
expressions directly.
Imagine we coud write SQL check expressions such as: "select {0} from b as
{1}", where {0} would be translated to valid identifier regex and spaces to
"any number of spaces". So this could be translated to a regex like
"select\s*\w*\s*from\s*b\s*as\s*\w*".
We keep our tests clean and only identify what's necessary.
Jon, do you have a Google code ID (a google id, in fact)? I'd like to add to
you to contributors, so you could make some tests directly on the SVN (maybe
in a branch for a start).
Pascal.
jabber/gtalk: [email protected]
msn: [email protected]
On Mon, Feb 23, 2009 at 14:35, Jonathan Pryor <[email protected]> wrote:
>
> On Mon, 2009-02-23 at 10:01 +0100, Pascal Craponne wrote:
> > the idea is interesting, because I also have problems maintaining a VM
> > with all the databases.
> > Anyway I see several limitations:
> > - This will require to rewrite all current tests
>
> Hence my suggestion that this would be /in addition to/, not a
> replacement for, the current tests. We want to keep the current tests
> as integration tests, to ensure that "end-to-end" functionality works.
>
> > - Making any small change (like the internal temporary objects naming)
> > would require to change all tests
>
> This is to be expected, somewhat. I'd consider it to be a feature,
> myself, so that the "externally visible" effects of an internal change
> are more noticeable.
>
> > - This makes any further optimization a pain.
> > As an example, I rewrote the SQL generation engine last spring/summer,
> > and even if the generated SQL is different is all ways from previous
> > engines, the existing tests helped me validating the engine. Also
> > (still my own story), some tests were complex, and I had no idea of
> > what it would look like in SQL (I'm not an SQL expert at all, and yes,
> > I rewrote an SQL generation engine :)), so until the engine worked I
> > had no idea of what tests should look like.
>
> It's not necessary to have the tests written and fully complete before
> the functionality is complete. In this case, I'd suggest doing the
> refactoring, then writing the tests to ensure that the functionality
> doesn't change in the future. (This also removes the "I don't know what
> the SQL should look like" issue, as you can just use the actual
> resulting SQL in the test, after you've written the functionality.)
>
> > - SQL is very different from one vendor to another. A good example is
> > how Skip() and Take() are handled in Oracle, SQL Server, and others.
>
> You'll notice that my approach solved this, by having a DataContractTest
> abstract base class (which has all the [Test] methods), and a
> MsSqlDataContextTest subclass which overrides DataContextTest methods.
> This allows subclasses to provide the actual SQL that's specific to that
> provider, without requiring that all databases accept the same SQL.
>
> > Regarding the tests, we could instead of a hard SQL string comparison
> > (which will totally break all tests after first change), use regular
> > expressions, so ignore internal names could be safely ignored, just
> > like maybe tables or columns names (without ignoring their
> > occurrence), whitespaces, comments, and so on?
>
> I'd be leery about using regular expressions, and would think that the
> current subclass approach would be sufficient.
>
> However, I wonder what sort of "internal names" would be present in the
> SQL that is being sent to the database....
>
> > I also suggest to keep the current tests, but restructure them in real
> > projects with real directories (currently they are all in the same
> > folder, we could probably create new projets in new directories with
> > links to shared files, instead of having all test projects in one
> > folder).
>
> Please! :-)
>
> - 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
-~----------~----~----~----~------~----~------~--~---
