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 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="" directory/myDatabase/${testOrProd}/Account.xml"/>
> > > > url="" 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="" directory/myDatabase/TEST/maps.config">
> > > > > or
> > > > > <sqlMaps url="" 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="">> > > > > >
> > > > > > -Gilles
