(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 > > > On 4/30/05, Ted Husted <[EMAIL PROTECTED]> wrote: >> >> If someone is after that much flexibility, then perhaps the elements should not be stored in static files at all. Perhaps, they should be kept in a database and retreived via a web service. The iBATIS >> configuration might then just specify URIs for the properties and the SQLMaps. >> >> We've seen the same sort of thing crop up when using language >> resources. Projects often outgrown static XML documents and need to move the language resources to a database. If a well-designed factory is used, the application or framework doesn't know the different. >> >> I don't have a need for such a thing myself, but it might be an interesting extension if someone had the itch. If we can specify a URI for the SQLMap and Properties elements, then the core might not need to change at all. iBATIS shouldn't care whether the file is being returned from the file system or a web service. >> >> Of course, the configuration is only read once at startup, and so the performance hit of reading the web service should be an acceptable trade off. >> >> HTH, Ted. >> >> On 4/29/05, Bob Hanson <[EMAIL PROTECTED]> wrote: >> > That's the whole point. I don't want to have to maintain a bunch of config files. If a DAL is only used in a single project then it was a waste of time to create the DAL. >> > >> > With the current setup every project that uses the DAL has to maintain its own set of <SqlMap> elements. Adding a new map to the DAL means having to update every single config file. If that new map is only on test (where it should be if you're just starting to implement it) then using the Properties trick to differentiate between test and prod will break. >> > >> > The benefit seems obvious to me. *shrugs* >> > >> > > What would your maps.config file look like? >> > >> > It would contain the current <SqlMaps> element which would contain one or more <SqlMap> elements. In other words, just cut out what appears in SqlMap.config and stick it in another file. >> > >> > On 4/29/05, Ron Grabowski <[EMAIL PROTECTED]> wrote: >> > > I doubt most people are in an environment where they have completely different names and locations for their sqlmap entries between their dev and production servers (i.e. _nothing_ in common). If someone >> was >> > > in such an environment, I would suspect they have already looking >> into >> > > writing a small NAnt file to do what they need. The problem with >> having >> > > a lot of config files: >> > > >> > > app.config >> > > providers.config >> > > log4net.config >> > > sqlmap.config >> > > maps.config >> > > >> > > is that you spend more time maintaining all the little files instead >> of >> > > just having a few smallish-medium sized file. Its annoying having to maintain someone else's project where there are many small config >> files >> > > scattered in various places throughout the system. >> > > >> > > What would your maps.config file look like? >> > > >> > > --- Bob Hanson <[EMAIL PROTECTED]> wrote: >> > > > Sure. But the separate file is even more flexible because it >> allows >> > > > you to have completely different names, add maps, subtract maps. Properties only allow you to change existing lines. What if I want >> to >> > > > add NewTable.xml to test but not to prod? >> > > > >> > > > With properties you also have to have a rigid file structure or >> else >> > > > you'll have to define propeties for every part of the path. >> > > > >> > > > Worst of all, you have to modify lines in every single map file as opposed to editing a single file. >> > > > >> > > > >> > > > On 4/29/05, Ron Grabowski <[EMAIL PROTECTED]> wrote: >> > > > > This is what property files were designed for: >> > > > > >> > > > > <?xml version="1.0" encoding="utf-8" ?> >> > > > > <settings> >> > > > > <add key="testOrProd" value="TEST" /> >> > > > > </settings> >> > > > > >> > > > > <sqlMaps> >> > > > > url="c:/some directory/myDatabase/${testOrProd}/Account.xml"/> url="c:/some directory/myDatabase/${testOrProd}/Order.xml"/> </sqlMaps> >> > > > > >> > > > > --- Bob Hanson <[EMAIL PROTECTED]> wrote: >> > > > > > I think one small change would go a long way towards making configuration as flexible as possible. >> > > > > > >> > > > > > Remove the <sqlMap> elements from SqlMap.config and allow >> > > > <sqlMaps> >> > > > > > to >> > > > > > specify a URL to a separate maps.config file like: >> > > > > > <sqlMaps url="c:/some directory/myDatabase/TEST/maps.config"> or >> > > > > > <sqlMaps url="c:/some directory/myDatabase/PROD/maps.config"> >> > > > > > >> > > > > > This way the maps can be defined in a single location. As my >> > > > example >> > > > > > above shows, it makes it very easy to switch between a test >> and >> > > > > > production version of the maps. If you are using a DAL you >> don't >> > > > have >> > > > > > to modify a bunch of elements in every SqlMap.config for every >> > > > single >> > > > > > project that is using the DAL. They would all just point to >> the >> > > > > > version of the maps.config file that they need. >> > > > > > >> > > > > > Then, for similar reasons, add back the ability to specify the location of providers.config in SqlMap.config so that it >> doesn't >> > > > have >> > > > > > to be included with every project. >> > > > > > >> > > > > > On 4/28/05, Gilles Bayon <[EMAIL PROTECTED]> wrote: >> > > > > > > Or used syntax as >> > > > > > > in the SqlMap.config >> > > > > > > >> > > > > > > <sqlMap >> > > > > > >> > > > > >> > > > >> > > >> url="E:/Projet/IBatisNet/Source/IBatisNet.Test/Maps/MSSQL/SqlClient/Account.xml"/> >> > > > > > > >> > > > > > > -Gilles >> >
