Just curious, why are you limited to 3.0 Beta 9? As for annotations vs. XML, I was worried about splitting between the two at first, and thought that it might be good to choose one approach and stick with it. But that would mean you'd have to choose XML, as annotations can't compete. That said, I've been working on a project mixing annotations and XML, and I'm very happy with the results. I've found that INSERT, UPDATE and DELETE statements pretty much always remain as annotations, along with simple SELECT statements. The only things I end up putting in XML are very complex queries that include collections or associations. Overall, it seems quite clean and easy to follow. I've never been in a situation where I was confused about it.
Cheers, Clinton 2010/2/18 Ing. Jan Novotný <novotn...@gmail.com> > Hello Clinton, > > many thanks for your answers. They made a lot of things much clearer to > me - "the whitepaper" set a lot of expectations in the minds of many people > (including me), so that's why I asked those questions. I am sure someone > will ask me those questions at the presentation, so I want to be prepared. > I found some more configuration options in the trunk, but for the > presentation I am limited to 3-beta-9 where they didnť work. But it's good > to know, that those issues got answered. > My final question - would you encourage using annotations after all? From > the limited experience with iBatis 3 I have, they could be used only to > simple cases, but they make the code fragmented among annotations and XML. I > can imagine that this could be very confusing in the large scale, so maybe I > should recommend to attendees of the presentation to better stick with good > old XML. What do you think? > > Thanks, > Jan > > Offtopic: > P.S.: you seem very resignated to the Java - does the folks from Microsoft > got you? :) > > 2010/2/18 Clinton Begin <clinton.be...@gmail.com> > >> Hi Jan, >> >> >> >> expectations come from iBatis 3 Whitepaper >> >> Just to be clear, it wasn't a "white paper" it was a community whiteboard >> for brainstorming ideas. So it contained goals and ideas, but there was >> never a commitment to any of them. >> >> >> >> Multilevel Configuration >> >> Ultimately I decided not to implement it this way because it became hard >> to trace where behavior was configured. To fully understand how a statement >> might behave or perform, you would have had to look in 3 places. I wasn't >> satisfied with that, so I made it to be either XML or Annotations per >> statement. You can happily mix mappers with annotations or xml statements, >> but each statement must use either one or the other. >> >> >> >> to state all properties in order to alter the single one >> >> That's configurable. See the docs under the automappingBehavior setting >> (I think that's what it's called). >> >> >>annotations >> >> You think it's unpleasant? You should have seen me the day that I had to >> remove WORKING CODE from my system because Sun changed the behavior of Java >> Annotations between Java 1.5 and 1.6. >> >> In a nutshell, circular references are not supported in the Annotations >> framework. All of your best hopes and dreams of having something better are >> dashed by this one limitation. There was a workaround in Java 1.5, but Sun >> considered it a compiler bug, so they "fixed" the workaround in JDK 1.6. If >> you want to see it, you can dig back through a few hundred commits and see >> where I removed that behavior. >> >> A shame. If this was C# I would have been able to fully realize the >> vision of where we wanted to take the annotation (or attributes in C#) >> approach. >> >> **>> 3 combinations of annotations and xml >> >> In general, I recommend using annotations for simple things, and use XML >> for anything more complicated. Sorry, but Java annotations are just too >> messy, limited and ugly. There's a million reasons why we had to scale back >> the behavior and limit it to what you see now. If you want to understand >> why, I encourage you to try to implement some of your suggestions. You'll >> find the same challenges. >> >> >> 4 automatic (generated) SQL >> >> Yes, I completely ditched the idea of generating SQL. It's just a road >> that I wasn't prepared to take iBATIS down. >> >> >> 5 dynamic sql in annotations >> >> Yes, SelectProvider and the SQL Builder framework are the only way (other >> than writing your own). I wasn't about to start putting XML embedded in SQL >> embedded in strings embedded in annotations... that's out of hand and bad >> practice IMHO. >> >> I appreciate your questions, but please realize that everything was >> considered. Some things were left out for very good design reasons, others >> because of limitations in Java and others we might just not have had a >> chance to implement yet. >> >> Clinton >> >> 2010/2/18 Ing. Jan Novotný <novotn...@gmail.com> >> >>> Hello, >>> >>> >>> I am going to have a presentation about iBatis 3 at Czech JUG. I have >>> a 3-year experience with iBatis-2 and now I am doing little research on >>> what's new in upcoming iBatis 3 release. Most of my expectations come from >>> iBatis 3 Whitepaper at the iBatis Confluence site. Now I am testing the new >>> version and there are some things I didn't expect. I will be very pleased if >>> anyone capable could answer me following questions so that I may forward >>> them to the attendees of CZ JUG: >>> >>> * 1) multilevel configuration* >>> Firstly I thought that there would be a chance to override less >>> prioritized level of configuration. Meaning, that if I have SQL represented >>> in an @Select annotation and I create XML statement in mapper file with the >>> same name, this XML declaration will take over the annotation and will be >>> used instead. Reality is that iBatis will fail to start complaining about >>> duplicate declaration. As I discovered, I can use only one or the other way >>> - I can combine XML file with annotation based Java DAO, but they must not >>> overlap in the sense of statement declaration. Is that right? Why is that >>> done this way? >>> Next I thought there could be some means to explicitly say, that >>> some parts of the lower configuration level fit for me and therefore ease my >>> life a little. Let say I have ResultMap statement in XML configuration and >>> 95% of its properties is fine by convention, but I need only to specify more >>> single property or declare association / collection mapping. In that case I >>> have to state all properties in order to alter the single one that is needed >>> to be extra taken care of (or at least these are my findings from the tests >>> I wrote). What I really want to say is: use convention to all properties >>> except those that I explicitly configure in XML - that is not possible, is >>> it? >>> >>> * 2) annotations* >>> Another unpleasant surprise was, that I am not able to get along >>> with annotations to specify <collection> mapping - annotation @Collection is >>> missing. Also @Association is not present - but as I discovered, it's >>> possible to write @Result annotations in the way that associated object gets >>> mapped. In documentation I found a statement, that annotations in Java >>> aren't powerfull enough to make some things possible, but I can't make up >>> why @Collection annotation is not possible to be made. >>> >>> * 3) combination of XML and annotations* >>> I tried combination of XML and annotations (due to lack of >>> @Collection annotation) to specify @Select annotation but specify output as >>> a ResultMap mapping in the XML configuration. But that's not possible too. >>> Mixing configuration from annotations and XML is not possible in any way I >>> guess. Ok, but is there any way how to reuse my annotations, to get the same >>> behaviour as reusing ResultMap mapping in different statements of XML >>> configuration?! >>> >>> * 4) automatic SQL implementation* >>> I didn't find any piece of this functionality. May I take it, that >>> this was completely discarded? >>> >>> * 5) annotations and dynamic SQL* >>> Finally I didn't find any clue how to use dynamic SQL in >>> annotations. Does that mean that @SelectProviders are the only way how to >>> make dynamic queries by the Java code? >>> >>> Thanks for your time and answers I can use in my presentation if >>> anyone asks. Please, don't be offended by my questions, generally I think >>> iBatis is a great DAO framework. >>> >>> Cheers Jan >>> >>> -- >>> -------------------------------------------------------------- >>> Ing. Jan Novotný >>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >>> http://blog.novoj.net >>> Myšlenky dne otce Fura >>> -------------------------------------------------------------- >>> >> >> > > > -- > -------------------------------------------------------------- > Ing. Jan Novotný > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > http://blog.novoj.net > Myšlenky dne otce Fura > -------------------------------------------------------------- >
