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