ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Zhu <scott...@gmail.com>
Subject Re: Vendor specific queries?
Date Wed, 07 Sep 2005 01:27:18 GMT
No, the way the localization look up work in java, you have one default 
property file, and the ones with locale postfix. For example, you have 
staticMessages.properties and staticMesage_en_GB.properties. In the latter 
one, you only store the british english specific tranlations. At runtime, if 
the locale is set to en_GB, it will always look up in 
staticMessages_en_GB.properties first, then staticMessages_en.properties (if 
it's there), then staticMessages.properties. By the same approach, we can 
have bar.xml for all generic queries, then bar_ORACLE.xml, bar_DB2.xml. We 
can use either the file name or name space concept.

 On 9/6/05, Prashanth Sukumaran <prashanthsukumaran@yahoo.com> wrote: 
> 
> I don't know if this would be a good idea. Consider your example of 
> Localization resource lookup(not the directory based approach but the file 
> based approach) for example the ApplicaitonResouces.properties in struts, 
> are you saying it is good to have one huge file with sections like INI file 
> for different language_Country. 
>  This does not make sense at all.
>  Considering the suggestion, then it would end up with all kinds of 
> different queries for different for databases in one large file. I wouldn't 
> do it. I don't know if others would.
>  Prashanth Sukumaran.
> 
> *Scott Zhu <scottzhu@gmail.com>* wrote:
> 
> Yes, we used some approach like this, but we have to do it on our own. I'd 
> like to see this to be done in iBatis. Essecially, this could work like 
> localization resource lookup in java, if the database type is oracle, it 
> first looks in that name space (or something), if it can't find the 
> statement there, it then falls back to the default name space one. So we 
> only need to define vendor specific statement in its own xml file. Just my 
> 2cents. 
> 
> On 9/6/05, Ron Grabowski <rongrabowski@yahoo.com> wrote: 
> > 
> > You could create different property files per each vendor that contain
> > database specific things (like the select key statement, GETDATE() , 
> > etc.) and use it this way:
> > 
> > <selectKey keyProperty="ID" resultClass="long">
> > ${SELECT_KEY}
> > </selectKey>
> > 
> > Some people use this property syntax to group database specific sql 
> > maps:
> > 
> > <sqlMap resource="/SqlMaps/${VENDOR}/Foo.xml"/>
> > <sqlMap resource="/SqlMaps/${VENDOR}/Bar.xml"/>
> > <sqlMap resource="/SqlMaps/${VENDOR}/Baz.xml"/>
> > 
> > A colleague of mine suggested an alternative approach that hasn't been
> > implemented yet. His idea is to add a namespace attribute to the
> > statement node and allow that to override a particular statement node.
> > For example if there are 30 statement nodes in Foo, Bar, and Baz and 
> > you need to override just one or two statement f or Oracle you would be
> > able to include the differing statements in their own small file:
> > 
> > <update id="Update" namespace="Foo">
> > ...
> > </update>
> > <select id="GetMany" namespace="Bar">
> > ...
> > </select>
> > 
> > The resource nodes would look something like this:
> > 
> > <sqlMap resource="/SqlMaps/Foo.xml"/> 
> > <sqlMap resource="/SqlMaps/Bar.xml"/>
> > <sqlMap resource="/SqlMaps/Baz.xml"/>
> > <sqlMap resource="/SqlMaps/${VENDOR}.xml"/>
> > 
> > Yes, that would require you to always have a Oracle.xml, MSSQL.xml,
> > etc. Maybe a "ignoreMissingSqlMapResource" setting is in order too ???
> > 
> > --- Patrick Lightbody <patrick@jivesoftware.com> wrote: 
> > 
> > > Hey guys - great work on iBatis. I finally spent some time on it and
> > > I
> > > must say I prefer this method of storage much more than other options
> > > out there. In fact, the next version of WebWork (whi ch I am a 
> > > developer
> > > for) will contain integration with iBatis. Now, on to my question:
> > >
> > > I've seen in the docs where vendor-specific features, especially
> > > around
> > > sequence handling, are done like so: 
> > >
> > > <select name="insertFoo-ORACLE" .../>
> > > <select name="insertFoo-MYSQL" .../>
> > >
> > > What I can't tell is if this is just some naming convention, or if
> > > something trickier is going on here. Can iBatis run certain 
> > > "versions"
> > > of a statement based on the database vendor it is currently connected
> > > to? If not, maybe this would be a good feature to add? In fact, any
> > > place a query could be written, if there could be an optional 
> > > "vendor"
> > > attribute that could be used, that would be great. The end result
> > > would
> > > be:
> > >
> > > <select name="insertFoo" ...>
> > > <selectKey keyProperty="ID" resultClass="long" 
> > > vendor="postgres">
> > > SELECT nextval('category_seq') as ID
> > > </selectKey>
> > > <selectKey keyProperty="ID" resultClass="long"
> > > vendor="oracle">
> > > SELECT nextval('category_seq') FROM dual as ID
> > > </selectKey>
> > > INSERT ...
> > > <selectKey keyProperty="ID" resultClass="long" 
> > > vendor="mssql">
> > > SELECT @@IDENTITY...
> > > </selectKey>
> > > </select>
> > >
> > > _________________
> > > Patrick Lightbody
> > > Professional Services 
> > > Jive Software
> > > patrick@jivesoftware.com
> > > www.jivesoftware.com <http://www.jivesoftware.com/>
> > > 317 SW Alder, Ste 500
> > > Portland, OR 97204 
> > > ph (503) 295-6552
> > > fx (503) 961-1047
> > 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>

Mime
View raw message