ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: iBatis annotation related questions
Date Fri, 19 Feb 2010 14:07:24 GMT
When is your workshop?

On 2010-02-18, Ing. Jan Novotný <novotnaci@gmail.com> wrote:
> Thank you guys for sharing your experience. It's pretty good to hear that
> combining annotations and XML approach works in practice.
>
> My first thought was, that in case of large systems I wouldn't be able tu
> guess whether I should look in the Java or XML first when searching for
> particular statement definition. Next thought was about portability - we
> were forced a couple of times to translate statements in the XML definitions
> from one DB dialect into another. That is something one must count with when
> writing pure SQL statements. But when they are scattered over these two
> kinds of files, I will have to move all statements from interfaces to the
> XML and then make a dialect translation. Maybe there could be a way of
> extending former interface with annotations override , but this doesn't seem
> much nice to me. What's your view on this?
>
> Btw. the presentation will be more of a workshop and I thought that
> everybody starts just with Maven pom and downloads few libraries from the
> public repositories. There the latest one is 3-beta-9. Of course with some
> effort I could compile new artifact form trunk a distribute it to their
> local repositories, you're right.
>
> Jan
>
> 2010/2/19 Nathan Maves <nathan.maves@gmail.com>
>
>> I completely agree.
>>
>> I too have a project using IB3 and I am really loving mixing the two
>> together.  I would give it a try before trying to corner yourself into
>> using
>> just one approach.
>>
>>
>> Nathan Maves
>> nathan.maves@gmail.com
>>
>>
>>
>> On Feb 18, 2010, at 4:09 PM, Clinton Begin wrote:
>>
>> 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ý <novotnaci@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.begin@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ý <novotnaci@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
>>> --------------------------------------------------------------
>>>
>>
>>
>>
>
>
> --
> --------------------------------------------------------------
> Ing. Jan Novotný
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> http://blog.novoj.net
> Myšlenky dne otce Fura
> --------------------------------------------------------------
>

-- 
Sent from my mobile device

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Mime
View raw message