Yeah, looks like support for this isnt built in, so hopefully there will be some way of overriding how it gets its config.
_____ From: Clough, Samuel (USPC.PRG.Atlanta) [mailto:[EMAIL PROTECTED] Sent: 06 June 2007 13:04 To: [email protected] Subject: RE: Multiple external <sqlmaps> Note, I haven't looked at any of the code or anything, but perhaps you could manually manage the loading and configuration of iBatis? I haven't looked at the code so I don't know how internal this is or if there are hooks there where you could build up the configuration. It would require some digging into the internals, but you might could just build your own configuration code that initializes iBatis however you like. Maybe iBatis even has a provider type model where you could supply the configuration based on your own method rather than it just parsing an xml file. _____ From: Tony Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 7:33 AM To: [email protected] Subject: RE: Multiple external <sqlmaps> Yeah, thats the element, but specifically what Im looking to do is have a bunch of ibatis mapping files as resources in an external assembly, but then rather than adding all of them individually in the sqlmap.config file of the host application, be able to add a map to another resource file in the assembly that then loads all of the mappings it contains? Cheers Tony _____ From: Miika Mäkinen [mailto:[EMAIL PROTECTED] Sent: 06 June 2007 12:16 To: [email protected] Subject: Re: Multiple external <sqlmaps> Hi Tony, I don't know for sure but sqlMapConfig element looks like what you are after: http://ibatis.apache.org/docs/tools/abator/afterRunning.html On 6/6/07, Tony Johnson <[EMAIL PROTECTED]> wrote: Anyone have any ideas on this? Cheers Tony _____ From: Tony Selke [mailto:[EMAIL PROTECTED] Sent: 05 June 2007 12:29 To: [email protected] Subject: RE: Multiple external <sqlmaps> I was also wondering the other day if there was some sort of "wildcard format" for the sqlMap node. All of my maps are in a single resource assembly, but it would still be nice to simply say "here's an assembly/directory, go get every resource/file with a name that matches the pattern *.*.ibatis.map.xml". *A most excellent product, BTW!* Tony From: Tony Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 6:56 AM To: [email protected] Subject: Multiple external <sqlmaps> Hi, I'm working on a large enterprise application that has a series of data access assemblies for different functional areas. For example, we might have one assembly that concentrates on customer details etc and another that looks after invoices. In each assembly, there are hundreds of embedded resource sqlmap configurations (generally one for each entity / view). When I come to pull these together into an application, my application's sqlmap.config file then has to list out all of these sqlmap configuration resources individually? Ideally what I'd like to do is have each assembly pull together its own <sqlmaps> section and then include these in my application's <sqlmaps> : eg: In sqlmaps.config as a resource in Project.Domain.Customers.dll: <sqlmaps> <sqlmap embedded="Project.Domain.Customers.Customer.xml"/> <sqlmap embedded="Project.Domain.Customers.Contact.xml"/> < etc> </sqlmaps> Then in sqlmaps.config as a resource in Project.Domain.Invoices.dll: <sqlmaps> <sqlmap embedded="Project.Domain.Invoices.Invoice.xml"/> <sqlmap embedded="Project.Domain.Invoices.InvoiceLine.xml"/> < etc> </sqlmaps> And finally to then use these in my application, my application's sqlmaps section just needs to look like this: <sqlmaps> <sqlmap embedded="Project.Domain.Customers.sqlmaps.config, Project.Domain.Customers"/> <sqlmap embedded="Project.Domain.Invoices.sqlmaps.config, Project.Domain.Invoices"/> </sqlmaps> Is this, or anything like it, possible without having to write out the hundreds of sql map config files in my application project ? Thanks, Tony _____ Princeton Retirement Group, Inc - Important Terms This E-mail is not intended for distribution to, or use by, any person or entity in any location where such distribution or use would be contrary to law or regulation, or which would subject Princeton Retirement Group, Inc. or any affiliate to any registration requirement within such location. This E-mail may contain privileged or confidential information or may otherwise be protected by work product immunity or other legal rules. No confidentiality or privilege is waived or lost by any mistransmission. Access, copying or re-use of information by non-intended or non-authorized recipients is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail. The transmission and content of this E-mail cannot be guaranteed to be secure or error-free. Therefore, we cannot represent that the information in this E-mail is complete, accurate, uncorrupted, timely or free of viruses, and Princeton Retirement Group, Inc. cannot accept any liability for E-mails that have been altered in the course of delivery. Princeton Retirement Group, Inc. reserves the right to monitor, review and retain all electronic communications, including E-mail, traveling through its networks and systems (subject to and in accordance with local laws). If any of your details are incorrect or if you no longer wish to receive mailings such as this by E-mail please contact the sender by reply E-mail. _____
