Hmmm...now if I went crazy and plopped in/replaced most of the NUnit SqlMap.config file with property keys, we'd be back to square one by basically editing 1 properties file with almost all the same values that would have been found in the SqlMap.config file! Might as well just edit the .config file directly and have commented/uncommented lines! :-)
Roberto On Sat, April 30, 2005 12:25, Roberto Rabe said: > (Oops! I didn't reply-all, so now forwarding message to the list!) > > Hi Clinton. > > The DataMapper has embedded resource feature... > > <sqlMap embedded="Account.xml, IBatisNet.DataMapper.Test"/> > > ...relative paths... > > <sqlMap resource="../../Maps/MSSQL/SqlClient/Account.xml"/> > > ...and the URI syntax that Gilles showed... > > <sqlMap > url="E:/Projet/IBatisNet/Source/IBatisNet.Test/Maps/MSSQL/SqlClient/Account.xml"/> > > I think the email thread is about only having 1 SqlMap.config file instead > of 1 for each different environment (if each environment has a different > set of SqlMaps) by moving out the <sqlMaps> section to its own config > file. If all environments had the same SqlMaps and only needed to change > paths, then the properties file's keys/values would work fine. > > As an example, our C# DataMapper NUnit SqlMap_xxx_yyy.config files could > probably be updated to just use property key/values instead of having 8 > diff't files to maintain! Meaning: > > <provider name="sqlServer1.1"/> gets replaced with a key > > and > > <sqlMap resource="../../Maps/MSSQL/SqlClient/Account.xml"/> "MSSQL" and > "SqlClient" get replaced with keys. > > Now, if our MS SQL Server tests needed one more map to test something MS > SQL Server, Bob's idea may help if I didn't want to go into the 1 > SqlMap.config file and keep commenting/uncommenting that specific MSSQL > map each time I wanted to change db from MSSQL to something else. > > Roberto > > > On Sat, April 30, 2005 11:55, Clinton Begin said: >> This is something already supported by the Java implementation. There > are only two modes supported, classpath resource (invalid in the .NET > world), and URI, which includes file://, http:// etc. >> >> With the Java implementation, the most popular solution is classpath > based resources, which gives the application the benefit of location >> transparency. >> Hence this issue has never been raised. Is there something >> iBATIS.NET<http://iBATIS.NET>can do to immitate this behaviour? >> (application relative SQL map locations?) >> >> Cheers, >> Clinton >>
