Details

      Description

      The attached patch is enhancing the current data model following last David's suggestion after some exchanges on dev ML. I just added a geoPointId to Container.
      I finally used float for latitude, longitude and elevation, instead of creating a new degree field type (numeric 18,6).
      Any comments are welcome.

      1. GeloLocation.patch
        36 kB
        Jacques Le Roux
      2. GeloLocation.patch
        36 kB
        Jacques Le Roux
      3. GeopointDataModel.patch
        9 kB
        Jacques Le Roux
      4. GeopointDataModel.patch
        13 kB
        Jacques Le Roux
      5. GeopointDataModel.patch
        11 kB
        Jacques Le Roux
      6. GeopointDataModel.patch
        11 kB
        Jacques Le Roux
      7. GeopointDataModel.patch
        12 kB
        Jacques Le Roux

        Activity

        Hide
        Jacques Le Roux added a comment -

        I have commited last changes in revision 738452

        Show
        Jacques Le Roux added a comment - I have commited last changes in revision 738452
        Hide
        Jacques Le Roux added a comment -

        I will add Postal Addresses, Facilites, Containers, and Fixed Assets examples later... Any help welcome...

        Show
        Jacques Le Roux added a comment - I will add Postal Addresses, Facilites, Containers, and Fixed Assets examples later... Any help welcome...
        Hide
        Jacques Le Roux added a comment -

        In the previous patch I forgot the uomId for elevation and I fixed also some typo in view-entities definitions

        Show
        Jacques Le Roux added a comment - In the previous patch I forgot the uomId for elevation and I fixed also some typo in view-entities definitions
        Hide
        Jacques Le Roux added a comment -

        A more complete patch with a 1st demonstration of use in Party Profile. It could be yet commited and enhanced later. Please review and test, thanks

        Show
        Jacques Le Roux added a comment - A more complete patch with a 1st demonstration of use in Party Profile. It could be yet commited and enhanced later. Please review and test, thanks
        Hide
        Jacques Le Roux added a comment -

        Updated patch with only GeoLocation changes (the AgreementEmploymentAppl switch is now in OFBiz)

        Show
        Jacques Le Roux added a comment - Updated patch with only GeoLocation changes (the AgreementEmploymentAppl switch is now in OFBiz)
        Hide
        Jacques Le Roux added a comment -

        David,

        In this new version I have added a ContainerGeoPoint since, as you pointed out, it makes much more sense.
        I have also added a relationship from PostalAddress to GeoPoint. I don't know why I missed this one. Too obvious, while searching for ones that may be missing, I guess :o)

        Show
        Jacques Le Roux added a comment - David, In this new version I have added a ContainerGeoPoint since, as you pointed out, it makes much more sense. I have also added a relationship from PostalAddress to GeoPoint. I don't know why I missed this one. Too obvious, while searching for ones that may be missing, I guess :o)
        Hide
        David E. Jones added a comment -

        For the Container entity: a Facility may not move but a Container typically will. Whatever is done, the geoPointId should not be on the Container itself. I would recommend just not worrying about it at this point because Containers aren't used much in OFBiz yet. Also, when a Container is in a Facility you can look up the geoPointId of the Facility. Otherwise, you would need a ContainerGeoPoint entity to keep track of a series of points over time like the others.

        On a side note, wasn't a big point of all of this to have a lat/long on a postal address? I don't see anything like that in this data model patch, so I'm not sure what you're thinking along those lines. I'd recommend adding a geoPointId to the PostalAddress entity (and not the ContactMech entity as this does not apply to all ContactMechs).

        -David

        Show
        David E. Jones added a comment - For the Container entity: a Facility may not move but a Container typically will. Whatever is done, the geoPointId should not be on the Container itself. I would recommend just not worrying about it at this point because Containers aren't used much in OFBiz yet. Also, when a Container is in a Facility you can look up the geoPointId of the Facility. Otherwise, you would need a ContainerGeoPoint entity to keep track of a series of points over time like the others. On a side note, wasn't a big point of all of this to have a lat/long on a postal address? I don't see anything like that in this data model patch, so I'm not sure what you're thinking along those lines. I'd recommend adding a geoPointId to the PostalAddress entity (and not the ContactMech entity as this does not apply to all ContactMechs). -David
        Hide
        Jacques Le Roux added a comment -

        Thanks to David's patience, I think the data model is ok now

        Show
        Jacques Le Roux added a comment - Thanks to David's patience, I think the data model is ok now
        Hide
        Jacques Le Roux added a comment -

        Yes of course a joint entity must join entities. It's obvious, but as you said you have to have write some to be acquainted with it. And as you may know, I'm more inclined to code. I guess I learn some with this work, reading books is not enough... practice, practice, pratice...

        Thanks for your support !

        Show
        Jacques Le Roux added a comment - Yes of course a joint entity must join entities. It's obvious, but as you said you have to have write some to be acquainted with it. And as you may know, I'm more inclined to code. I guess I learn some with this work, reading books is not enough... practice, practice, pratice... Thanks for your support !
        Hide
        David E. Jones added a comment -

        For the PartyGeoPoint and FixedAssetGeoPoint entities they should have a type one relationship to each other record they refer to, in this case both the Party entity (which you have) and the GeoPoint entity (which you don't have).

        On a side note: this is why I'm a little picky about who makes data model changes... they aren't too complex but for anyone that hasn't done them a fair amount it is easy to miss things, and once the entities are used becomes difficult to fix. In any case, these are looking pretty good, so great job on your efforts here.

        Show
        David E. Jones added a comment - For the PartyGeoPoint and FixedAssetGeoPoint entities they should have a type one relationship to each other record they refer to, in this case both the Party entity (which you have) and the GeoPoint entity (which you don't have). On a side note: this is why I'm a little picky about who makes data model changes... they aren't too complex but for anyone that hasn't done them a fair amount it is easy to miss things, and once the entities are used becomes difficult to fix. In any case, these are looking pretty good, so great job on your efforts here.
        Hide
        Jacques Le Roux added a comment - - edited

        Afterthought : I think I was thinking that the relationship comes from Party to its geo location history. But I really don't know why I used a one relationship from Party to its geo location history. This makes no sense at all... I guess I did copy the lines from somewhere but did not think much about their contents...

        Thanks for your clear explanation ! I forgot that the entity engine is able to automatically create the reverse many relationship. It"s easier to do it in this direction...

        Show
        Jacques Le Roux added a comment - - edited Afterthought : I think I was thinking that the relationship comes from Party to its geo location history. But I really don't know why I used a one relationship from Party to its geo location history. This makes no sense at all... I guess I did copy the lines from somewhere but did not think much about their contents... Thanks for your clear explanation ! I forgot that the entity engine is able to automatically create the reverse many relationship. It"s easier to do it in this direction...
        Hide
        Jacques Le Roux added a comment -

        Thanks David,

        For AgreementEmploymentAppl, its package-name="org.ofbiz.party.agreement" so I moved it up to its block (from org.ofbiz.party.party to org.ofbiz.party.agreement). If you think it should not be in the party entitymodel it should be discussed in dev ML as I have no ideas why it was put there... But it seems correct to me (its about employment and agreement after all, so org.ofbiz.party.agreement sounds to be the right package)

        For PartyGeoPoint and FixedAssetGeoPoint it's clearer now I will change the direction of relations.

        I will then provides some data, and will make some tests...

        Show
        Jacques Le Roux added a comment - Thanks David, For AgreementEmploymentAppl, its package-name="org.ofbiz.party.agreement" so I moved it up to its block (from org.ofbiz.party.party to org.ofbiz.party.agreement). If you think it should not be in the party entitymodel it should be discussed in dev ML as I have no ideas why it was put there... But it seems correct to me (its about employment and agreement after all, so org.ofbiz.party.agreement sounds to be the right package) For PartyGeoPoint and FixedAssetGeoPoint it's clearer now I will change the direction of relations. I will then provides some data, and will make some tests...
        Hide
        David E. Jones added a comment -

        What is the "AgreementEmploymentAppl" entity doing in there?

        As for PartyGeoPoint, it should point to Party but no need for one in the other direction, the entity engine would automatically add the reverse type "many" relationship.

        It wouldn't really make much sense to try to have a type one relationship going from Party to PartyGeoPoint, but yes if you wanted to do that you would have to have fields for the full PK of PartyGeoPoint on the Party entity (but no, we don't want to do that...).

        -David

        Show
        David E. Jones added a comment - What is the "AgreementEmploymentAppl" entity doing in there? As for PartyGeoPoint, it should point to Party but no need for one in the other direction, the entity engine would automatically add the reverse type "many" relationship. It wouldn't really make much sense to try to have a type one relationship going from Party to PartyGeoPoint, but yes if you wanted to do that you would have to have fields for the full PK of PartyGeoPoint on the Party entity (but no, we don't want to do that...). -David
        Hide
        Jacques Le Roux added a comment -

        By adding something like that in entity DataSource

        dataSourceId dataSourceTypeId description
        YAHOO GEO_POINT Terrestial position from Yahoo
        GOOGLE GEO_POINT Terrestial position from Google
        ...

        I wait to be sure of the data model before adding any data and labels (one label, at least, is needed for GEO_POINT)

        Show
        Jacques Le Roux added a comment - By adding something like that in entity DataSource dataSourceId dataSourceTypeId description YAHOO GEO_POINT Terrestial position from Yahoo GOOGLE GEO_POINT Terrestial position from Google ... I wait to be sure of the data model before adding any data and labels (one label, at least, is needed for GEO_POINT)
        Hide
        BJ Freeman added a comment -

        I see you chose Dataresource
        how do you see linking this to the source of the data

        Show
        BJ Freeman added a comment - I see you chose Dataresource how do you see linking this to the source of the data
        Hide
        Jacques Le Roux added a comment -

        Thank for your comment David,

        1 and 2 done in new patch, I also moved above (in its block) the entity AgreementEmploymentAppl.
        For 3, I get warns about joint entities FixedAssetGeoPoint and PartyAssetGeoPoint and field missing in related entities, like <<The number of primary keys (3) of related entity PartyGeoPoint does not match the number of keymaps (1) for relation of type one "PartyGeoPoint" of entity Party.>>. I foresaw that but I did not know how to deal with since adding the required fields (geoPointId and fromDate) to Party and FixedAsset sounds weird to me. Maybe we could remove the geoPointId from keymaps in joint entities, since fromDate should be sufficient, and then add only the fromDate field in Party and Fixedasset, maybe with a thruDate field too then ?

        Show
        Jacques Le Roux added a comment - Thank for your comment David, 1 and 2 done in new patch, I also moved above (in its block) the entity AgreementEmploymentAppl. For 3, I get warns about joint entities FixedAssetGeoPoint and PartyAssetGeoPoint and field missing in related entities, like <<The number of primary keys (3) of related entity PartyGeoPoint does not match the number of keymaps (1) for relation of type one "PartyGeoPoint" of entity Party.>>. I foresaw that but I did not know how to deal with since adding the required fields (geoPointId and fromDate) to Party and FixedAsset sounds weird to me. Maybe we could remove the geoPointId from keymaps in joint entities, since fromDate should be sufficient, and then add only the fromDate field in Party and Fixedasset, maybe with a thruDate field too then ?
        Hide
        David E. Jones added a comment -

        A couple of thoughts:

        1. make sure it is GeoPoint.geoPointId, not GeoPointId
        2. the comment on the comment field should go in the field->description sub-element
        3. make sure to start a fresh copy of OFBiz with this running (with add missing set to false if you don't want it to change your db) and make sure the entity engine checks don't complain about anything

        Show
        David E. Jones added a comment - A couple of thoughts: 1. make sure it is GeoPoint.geoPointId, not GeoPointId 2. the comment on the comment field should go in the field->description sub-element 3. make sure to start a fresh copy of OFBiz with this running (with add missing set to false if you don't want it to change your db) and make sure the entity engine checks don't complain about anything

          People

          • Assignee:
            Jacques Le Roux
            Reporter:
            Jacques Le Roux
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Development