Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    JPA2DataSource generation

    Have you changed the way fields are generated from an entity? In 3.0 we were able to add a setter and getter method and derive a value that wasnt actually persisted by the entity and declare a field that matched the getter and setter in the ds.xml and it properly invoke the methods for that field. That does not seem to be the case in 4.1.

    Also is it valid to declare a ds.xml for an Embeddable object?

    #2
    Have you changed the way fields are generated from an entity? In 3.0 we were able to add a setter and getter method and derive a value that wasnt actually persisted by the entity and declare a field that matched the getter and setter in the ds.xml and it properly invoke the methods for that field. That does not seem to be the case in 4.1.
    This should continue to work fine. Of course you won't actually be able to query on such a field. Can you show the definition?

    Also is it valid to declare a ds.xml for an Embeddable object?
    Here again, could you show the definition and indicate what behaviors you are hoping to get?

    Comment


      #3
      Let's create a simple example to demonstrate what I am trying to accomplish. We have several entities that encapsulate a coordinate location. We persist the values in decimal degrees as this is what the server logic, and hardware components use, but our users typically enter coordinates in MGRS


      So then I use the batchDataSourceGenerator to generate a ds.xml for me and the resulting ds.xml will provide a field for coordinate_latitude and coordinate_longitude but entirely ignore the mgrs getters and setters. If I try to manually insert a coordinate_mgrs field with the proper valueXPath and type the value is perpetually returned as null as if it does not actually attempt to call the getter.
      If I define a getter and setter directly in the HasCoordinate entity the batchDataSourceGenerator ignores the getter and setter as well.

      So what I am wondering is what is the appropriate approach to take to be certain that I can get the mgrs value to the client, have the client set the coordinate via an mgrs string, and be able to properly construct a HasCoordinate entity on the server to persist.
      Last edited by jpappalardo; 24 Sep 2014, 09:12.

      Comment


        #4
        Alright disregard that my mapping of coordinate_mgrs does not work, it turns out there was a flaw in the logic but it was actually returning the value Coordinate.getMgrs() supplied. But it would still be nice to know if there is a valid way that I could wrap Coordinate with a ds.xml so that I can define its fields once, and then declare a coordinate type in all entities that have coordinate?

        Comment


          #5
          You can create a separate .ds.xml for the Coordinate object. Say you give it the ID "Coordinate" - then in other .ds.xml file you can use that as the "type" attribute for a field and you will get nested Records when data is delivered to the client.

          Comment


            #6
            Perhaps you can help me understand what I am doing wrong then because when I try creating a DataSource for an Embeddable I always end up getting exceptions.



            Attempting to load this ds results in the following:
            Last edited by jpappalardo; 24 Sep 2014, 09:12.

            Comment


              #7
              You should remove the serverConstructor setting, because this won't be a DataSource you can actually query. You can keep beanClassName though.

              Comment


                #8
                This gets me the data to the client, however when I try to execute a datasource dmi method that declares an entity instance for its only argument I get the following error.

                Couldn't set property 'coordinate' for datasource 'CdlLocationLookup_JPA'. Actual error: java.lang.ClassCastException: com.isomorphic.datasource.BasicDataSource cannot be cast to com.isomorphic.jpa.JPADataSource.

                Is there a way to remedy this?

                Comment


                  #9
                  Yes, it's easy to avoid by not just trying to use auto-population of beans with your JPA Embeddable. For example, just create the bean via "new" and use DataSource.setProperties() *omitting* properties for the Embeddable, and calling the setter for that yourself.

                  We'll see if we can reproduce the error you posted - can you show the rest of the server log leading to this error?

                  Comment


                    #10
                    I pretty much gave you everything it displayed : Contents of server.log
                    The operation type is custom so JPA2DataSource our custom DataSource extends doesn't really do anything.
                    Last edited by jpappalardo; 24 Sep 2014, 09:12.

                    Comment


                      #11
                      The following code works with less effort


                      and successfully manages to handle the coordinate values
                      Last edited by jpappalardo; 24 Sep 2014, 09:13.

                      Comment


                        #12
                        Although you used workaround code to get rid of your issues, it is still important to Isomorphic to identify and fix them.

                        I cannot reproduce java.lang.ClassCastException issue you reported recently, could you please send more info on that?

                        I'd appreciate if you could set log level to DEBUG for com.isomorphic.datasource.DataSource and com.isomorphic.jpa.JPADataSource classes and post more detailed log here.
                        I also would like to see how exactly your code looks like for these:
                        - datasource ds.xml config files (for both entity datasource and embedded datasource)
                        - your DMI class

                        Thanks!

                        Comment


                          #13
                          Here is a set of real ds.xml I am using in this application. As you read this please understand that I do know that for crud operations we are supposed to make them look like crud operations to your framework, however we do have our reasons we break your "rule" on this matter.

                          Custom DS:


                          Entity ds.xml:

                          Embeddable ds.xml


                          DMI class:


                          request


                          server.log:


                          The result being that
                          Last edited by jpappalardo; 24 Sep 2014, 09:13.

                          Comment


                            #14
                            Out of curiosity, is debug output of this nature normal? Because I end up with a bunch of this during the precache phase.
                            Last edited by jpappalardo; 24 Sep 2014, 09:14.

                            Comment


                              #15
                              I'm actually having problems with constructing entities that have relationships as well, perhaps this is somehow related?

                              Parent ds.xml


                              child ds.xml


                              childs child ds.xml


                              server.log
                              Last edited by jpappalardo; 24 Sep 2014, 09:14.

                              Comment

                              Working...
                              X