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, that's the element, but specifically what I'm 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. 

--------------------------------------------------------

Reply via email to