It's not about this. It's just that there is a bunch of #if in all tests
source files, and this is just because of me :)
Pascal.

jabber/gtalk: [email protected]
msn: [email protected]



On Sat, Mar 28, 2009 at 15:18, Giacomo Tesio <[email protected]> wrote:

> What about using (the mono/dblinq) xmlmappingsouce for mapping and simply
> switch the mapping source?
>
> would this remove the need for different namespaces?
>
> On Sat, Mar 28, 2009 at 2:14 PM, Pascal Craponne <[email protected]> wrote:
>
>> After tests, no, it just doesn't work.  My idea: we (I) could write a
>> small tool to update all test files, and add #if'ed namespaces
>> automatically.
>> Pascal.
>>
>> jabber/gtalk: [email protected]
>> msn: [email protected]
>>
>>
>>
>>   On Thu, Mar 5, 2009 at 08:09, Pascal Craponne <[email protected]> wrote:
>>
>>> I have no idea. I'll make a test and let you know.
>>> Pascal.
>>>
>>> jabber/gtalk: [email protected]
>>> msn: [email protected]
>>>
>>>
>>>
>>>   On Thu, Mar 5, 2009 at 05:59, Jonathan Pryor <[email protected]> wrote:
>>>
>>>> The #if removal fix has been committed to the testing-no-db branch.
>>>>
>>>> Any word on whether namespaces are still a problem for ReSharper?
>>>>
>>>> - Jon
>>>>
>>>> On Wed, 2009-03-04 at 23:14 +0100, Pascal Craponne wrote:
>>>>
>>>> 1. I did this, because I use ReSharper to run unit tests from Visual
>>>> Studio. And ReSharper is confused when all tests are in the same namespace,
>>>> because it thinks they are the same.
>>>>
>>>> And all namespaces can be changed at once, with a smart find and
>>>> replace, I think (as far as I remember, that's what I did)
>>>>
>>>>
>>>>
>>>> 2. Nice idea. I buy it (or take it if you give it for free).
>>>>
>>>>
>>>> Pascal.
>>>>
>>>> jabber/gtalk: [email protected]
>>>> msn: [email protected]
>>>>
>>>>
>>>>
>>>> On Wed, Mar 4, 2009 at 23:02, Jonathan Pryor <[email protected]> wrote:
>>>>
>>>>  It occurs to me that eventually we will want to add support for
>>>> additional SQL providers [0].
>>>>
>>>> This isn't difficult, but it is annoying, as the tests are full of
>>>> conditional compilation logic to switch between the various providers,
>>>> change the namespace name, etc.:
>>>>
>>>> #if MYSQL
>>>> namespace Test_NUnit_MySql
>>>> #elif ORACLE
>>>> #if ODP
>>>>         namespace Test_NUnit_OracleODP
>>>> #else
>>>>         namespace Test_NUnit_Oracle
>>>> #endif
>>>>
>>>> Changing ~58 files to add new conditional compilation logic for 
>>>> *each*provider doesn't strike me as a "fun time."
>>>>
>>>> Thus, two questions:
>>>>
>>>> 1. Is there any reason to change the namespace based on the assembly
>>>> it's going into?  I don't understand why the above is done ~everywhere, 
>>>> just
>>>> to change the namespace of the tests, as they're going to be in separate
>>>> assemblies anyway.
>>>>
>>>> Ideally, we could remove this conditional compilation logic and just use
>>>> the same namespace for everything.
>>>>
>>>> 2. TestBase.cs is more complicated, as it wants to define the
>>>> XSqlConnection, XSqlCommand, and xint types for each provider.
>>>>
>>>> xint doesn't seem to actually be used, so it should be removed.
>>>>
>>>> XSqlConnection and XSqlCommand are a little harder to remove, but there
>>>> is a simple solution: partial classes.
>>>>
>>>> We could "abstract" out TestBase to depend upon members/properties based
>>>> upon interfaces instead of concrete types, e.g. code would assume the
>>>> presence of a `IDbConnection CreateConnection(string)' method, and use
>>>> CreateConnection(connStr) instead of `new XSqlConnection(connStr)'.
>>>>
>>>> Next, each Test project could supply the "other half" of TestBase,
>>>> providing the SQL provider-specific members which TestBase uses, e.g.:
>>>>
>>>> IDbConnection CreateConnection(string s)
>>>> {
>>>>     return new SqliteConnection(s);
>>>> }
>>>>
>>>> This should allow removing most of the conditional logic within TestBase
>>>> to be removed, moving provider-specific logic into the provider-specific
>>>> projects.
>>>>
>>>> Thoughts?
>>>>
>>>> - Jon
>>>>
>>>> [0] Offhand, SQL Server Compact Edition and Mono.Data.Sqlite, if we
>>>> don't want to wholesale migrate from System.Data.SQLite to Mono.Data.Sqlite
>>>> (see previous email).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>   >>
>>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to