one-way and bi-directional mappings...

Help
2005-08-10
2013-05-02
1 2 > >> (Page 1 of 2)
  • Richard Lemesle

    Richard Lemesle - 2005-08-10

    Hi,

    We are currently testing dozer and it works well !

    We need to use "method" attributes in the mapping file for our relations defined by the following API :

    Iterator getRelatedObjects()
    addRelatedObject(RelatedObject ro)
    removeRelatedObject(RelatedObject ro)

    And we have the following two limitations :

    - getRelatedObjects() must return a List instead of an Iterator

         -> using iterator instead of list prevent developers to add or remove directly RelatedObject into the returned list. So, can you allow the method to return an iterator, a list or an array ?

    - This mapping of relations must be one-way only

        -> to make the mapping bi-directional, we need to define two one-way mappings and we need to duplicate in these two mappings all the bi-directional mapping for the attributes. What do you think of allowing method customization like this on a bi-directional mapping :

        <field>
          <A>relatedObject</A>
          <B>relObj</B>
          <originalGetMethod>getRelatedObjects</originalGetMethod>
          <originalSetMethod>addRelatedObject</originalSetMethod>
          <destinationGetMethod>getRelObjs</destinationGetMethod>
          <destinationSetMethod>addRelObj</destinationSetMethod>
        </field>

    Thanks again for your great product,

    Richard.

     
    • Ben Sullins

      Ben Sullins - 2005-08-10

      Richard,

      Thanks for the feedback, we will consider some of your suggestions.  BTW, wouldn't iterator.remove() still be an issue for you?

      We are in the process of planning the next release, maybe some of these suggestions will make it :) 

      thanks,

      Ben

       
    • Richard Lemesle

      Richard Lemesle - 2005-08-10

      Ben,

      The returned iterator will throw an UnsupportedOperationException on its remove() method ;-)

      When the next release will be downloadable ?

      Thanks again,

      Richard.

       
    • Ben Sullins

      Ben Sullins - 2005-08-10

      :)

      Not sure on the next release, but it won't be too long.  Although I am not guaranteeing we will support all of your suggestions.  the team will meet and discuss. 

       
      • Richard Lemesle

        Richard Lemesle - 2005-08-10

        As you said, these are only suggestions ;-)

        Richard.

         
    • Ben Sullins

      Ben Sullins - 2005-08-19

      Richard,

      We have completed this change, look to see it in the next release very soon.  You can see the actual docs for it (after release) in the advanced property mapping section.

      Ben

       
      • Richard Lemesle

        Richard Lemesle - 2005-08-22

        Thanks !

        That's Great ;-)

        But we are always unsatisfied ;-)

        What's the difference between that :

        <field-method>
          <A type="method">buildCar</A>
          <B type="method">addCar</B>
        </field-method>

        and this new form (instead the fact that the first one has the one way limitation ?) :

        <field-method>
          <A theGetMethod="buildCar">car</A> 
          <B theSetMethod="addCar" >car</B> 
        </field-method>

        Is the first form always relevant ? Can't it be replaced by the second one ?

        Does this also work with list (Iterators, List, Arrays) attibutes ?

        The fact that the get method return an iterator (or a subtype of iterator), a list (or a subtype of List) or an array means that it's an iterate mapping...

        If so, the iterate method mapping is no more relevant too.

        <field-iterate-method>
          <A>appleComputers</A>
          <B type="method">addComputer</B>
          <destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>      
        </field-iterate-method>

        Can then be replaced by :

        <field-method>
          <A>appleComputers</A>
          <B theSetMethod="addComputer">computer</B>
          <destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>      
        </field-method>

        And then, my last question is why calling this mapping <field-method> instead of <field> ?

        <field>
          <A theGetMethod="buildCar">car</A> 
          <B theSetMethod="addCar" >car</B> 
        </field>

        is simpler than :

        <field-method>
          <A theGetMethod="buildCar">car</A> 
          <B theSetMethod="addCar" >car</B> 
        </field-method>

        That's all folks ;-)

        I must say that this is by far the best mapping framework I have seen.

        Richard.

         
        • Franz Garsombke

          Franz Garsombke - 2005-08-22

          Thanks for the great feedback. I will work with Ben on re-factoring this into something a little more intuitive. Most of the iterate/method map stuff was an afterthought. We didn't know how many people in the community we need functionality like that. I'll let you know what we come up with.

          Thanks,

          Franz

           
          • Richard Lemesle

            Richard Lemesle - 2005-08-31

            Hi Franz,

            I just take a look at the release notes and saw nothing about field-method refactoring...

            Will this be done in a further version ?

            I thought this version will allow list attributes (as well as iterators ;-) ) and make  field-iterate-method irrelevant..

            Actually, we need to duplicate the whole mapping description to make 2 one way mappings just because we must use the field-iterate-method...

            I hope this will take place in a further release soon ;-)

            Thanks,

            Richard.

             
            • Franz Garsombke

              Franz Garsombke - 2005-08-31

              Hey Richard -

              We are still working on this for the 1.5.1 release. I will let you know when we get close to putting this out.

              Thanks.

              Franz

               
              • Richard Lemesle

                Richard Lemesle - 2005-08-31

                Good news ;-)

                I'm now waiting for this 1.5.1 release !

                Thanks again,

                Richard.

                 
              • Richard Lemesle

                Richard Lemesle - 2005-09-06

                Hi Franz,

                Just a little post to make the forum alive ;-)

                Are you close to put the 1.5.1 release out ?

                Richard.

                 
                • Franz Garsombke

                  Franz Garsombke - 2005-09-06

                  Hey Richard -

                  Let me get an update from the team. I think some of them might be OOO today.

                  Did we have a thread stating exactly what needed to be done for the field 'method' stuff?

                  I know the inheritance piece is close to being done.

                  Thanks,

                  Franz

                   
                  • Richard Lemesle

                    Richard Lemesle - 2005-09-06

                    Hi,

                    I don't think there is an other thread than this one about the 'field-method'  refactoring...

                    In this thread, my post dated '2005-08-22 16:03' try to explain why a suppression of the field-method as well as field-iterate-method would be interesting (simpler and bi-directionnal mappings).

                    Currently, we must use field-iterate-method for all our compositions between classes (because our set method is called addXxxx) and so we need to do 2 uni-directionnal mappings...

                    Good news if inheritance is close to be done ;-)

                    Thanks,

                    Richard.

                     
                    • Franz Garsombke

                      Franz Garsombke - 2005-09-06

                      Richard -

                      I got rid of field-method altogether. This works in both directions.

                            <field>
                              <A theSetMethod="placeValue" theGetMethod="buildValue">value</A>
                              <B>value</B> 
                            </field>

                          <field> <!-- this always assumes non-cumulative since the getMethod() returns a Car and not a List. We have no way of adding to the list since we can not access it -->
                            <A theGetMethod="buildCar">cars</A>
                            <B theSetMethod="addCar">vehicles</B>  <!-- maps to the type of the argument, assumes only one method name -->
                          </field>  

                      I should finish iterate tomorrow. So probably release on Thursday after merging the inheritance patch.

                      This works one-way...now I just need to get it working the other way.
                          <!-- Iterate Method Mapping -->
                          <field-iterate-method>
                            <A>appleComputers</A>
                            <B theSetMethod="addComputer">computers</B>
                      <destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>      
                          </field-iterate-method>          

                      Thanks,

                      Franz

                       
                      • Richard Lemesle

                        Richard Lemesle - 2005-09-07

                        Great !

                        So we will make a bi-directional mapping like that  ? :

                        <field-iterate-method> 
                        <A theGetMethod="getAppleComputers" theSetMethod="addAppleComputer" >appleComputers</A> 
                        <B theGetMethod="getComputers" theSetMethod="addComputer">computers</B> 
                        <sourceTypeHint>net.sf.dozer.util.mapping.a.AppleComputer</sourceTypeHint> 
                        <destinationTypeHint>net.sf.dozer.util.mapping.b.Computer</destinationTypeHint> 
                        </field-iterate-method>

                        This would be a good thing ! (converting apple computers to generic pc computers and the reverse will then be possible ;-)

                        But is it necessary to specify sourceTypeHint and destinationTypeHint and if we do not specify these, can Dozer take the class specified for the set method parameter instead ?

                        Thanks,

                        Richard.

                         
                        • Franz Garsombke

                          Franz Garsombke - 2005-09-07

                          Richard -

                          I'm pretty sure I have it all working. These two examples show iterating bi-directional. You do need to have a hint for any fields that are denoted as 'iterate'. Both fields can be iterate...or just one. You can also mix and match the method level set() and get() attributes.

                              <!-- Iterate Method Mapping -->
                              <field>
                                <A>appleComputers</A>
                                <B theSetMethod="addComputer" type="iterate">computers</B>
                                <destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>      
                              </field>

                              <!-- Iterate Method Mapping -->
                              <field>
                                <A theSetMethod="addCar" theGetMethod="myIterateCars" type="iterate">iterateCars</A>
                                <B theSetMethod="addIterateCar" type="iterate">iterateCars</B>
                                <sourceTypeHint>net.sf.dozer.util.mapping.vo.Car</sourceTypeHint>      
                                <destinationTypeHint>net.sf.dozer.util.mapping.vo.Car</destinationTypeHint>      
                              </field>

                          This should be in tonight or tomorrow morning. Just need to merge the inheritance stuff.

                           
                          • Richard Lemesle

                            Richard Lemesle - 2005-09-07

                            Hi Franz,

                            We could not hope for a better solution !

                            We will test that as soon as the 1.5.1 will be released ;-)

                            Thanks a lot,

                            Richard.

                             
    • Ben Sullins

      Ben Sullins - 2005-08-22

      well, yes there are some definite overlaps there.  I was mostly trying to get you a usable fix as fast as possible.  I will go back and refactor the whole section this week. 

       
    • seb

      seb - 2005-08-23

      Hi guys,

      sorry but it's for a bug again, slighty more difficult than the documentation one ;-)
      Well, i found that theSetMethod and theGetMethod don't work when applied on 'B' :

      * the working xml :
      <mapping>
        <classA>A</classA>
        <classB>B</classB>
        <field-method>
          <A theGetMethod="takeA" theSetMethod="giveA">myA</A>
          <B>b</B>
        </field-method>
      </mapping>

      * the no-working one :
      <mapping>
        <classA>fr.maaf.test.mapping.dozer.B</classA>
        <classB>fr.maaf.test.mapping.dozer.A</classB>
        <field-method>
          <A>b</A>
          <B theGetMethod="takeA" theSetMethod="giveA">myA</B>
          </field-method>
      </mapping>

      I just put classes on the reverse order, and it doesn't work anymore. The message is :

      Error in loading dozer mapping file: dozerBeanMapping.xml : net.sf.dozer.util.mapping.MappingException: net.sf.dozer.util.mapping.MappingException: Unable to determine read method for field: myA class: class A

      So it's also impossible to use Custom set() and get() methods in a bi-directional way :-)

      I think that's all (today ;-) )
      Bye
      Seb, Dozer tester 8-D

       
      • Franz Garsombke

        Franz Garsombke - 2005-08-23

        Thanks Seb. We are re-visiting this functionality this week and re-architecting the way it works. It is still lacking in a few things. Should have it re-factored by next week.

        Thanks.

        Franz

         
    • Ben Sullins

      Ben Sullins - 2005-08-23

      Sorry about the bug, I did not test if fully because I was trying to get it out so fast.

       
    • seb

      seb - 2005-08-23

      Don't worry, i'm here to test ;-)

       
    • Ben Sullins

      Ben Sullins - 2005-08-23

      This is now fixed.  It was simply a problem in the dozer castor mapping.

       
    • Richard Lemesle

      Richard Lemesle - 2005-09-08

      Hi,

      We have classes with the following API :

      Iterator getComputers()
      void addComputer(Computer computer)
      void removeComputer(Computer computer)

      We choose to use Iterator instead List in these API to be sure that the only way for developpers to add a computer is to do :

      container.addComputer(c)

      They don't have API allowing :

      container.getComputers().add(c)

      which allow to add something in a container in a way that the container isn't aware of this operation.

      The problem is Dozer doesn't let us defined such API ;-(

      Why "iterate" fields (with this attribute of the 1.5.1 release) can't have a get method returning an Iterator ?

      We can modify our programming rules to make getXxxx returning List instead Iterators but I liked a lot the fact that we can have our programming rules and tell Dozer these rules (instead of modifying these)....

      Richard.

       
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks