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