[Geoserver-users] App-Schema: Inheritance question

Hello,

I was playing around with app-schema and trying to do inheritance.

I’ve got the following classes: (all exist within same namespace of ‘company’)
There are 3 separate xsd’s
(person/employee/customer- people.xsd)
(manager - people-core.xsd)
(branchmanager - people-retail.xsd)

Person (fields: name,age)
^-Employee (fields: employeeID,salary) ^- Customer (fields: custID,revenue)

^-Manager (fields: managementGroup)
^-BranchManager (fields: branchID)

When I try to refer to ‘salary’ from within the BranchManager it claims that it does not exist.

eg.

company:branchID pemb_brid company:salary pe_salary

The DB table for branchManager has that field as expected.

Of course from the ‘Employee’ app-schema I can refer to it just fine using ‘company:salary’.

What am I missing ?

The XSD’s specify the substitution groups ok, (example below of ‘employee’)

Have attached full xsds.

The targetTypes schemaUri is set to the correct one for ‘branchManager’ (people-retail.xsd) that has an ‘include’ to the core people.xsd

people-core.xsd (1.32 KB)

people-retail.xsd (1.34 KB)

people.xsd (2.81 KB)

Please send us the full error message that you get (include a stack trace from the logs if you have one), and your mapping file.

Your schemas look good. Good job using FullMoon to generate them!

Kind regards,
Ben.

On 02/10/13 15:44, snuffy wrote:

Hello,

I was playing around with app-schema and trying to do inheritance.

I've got the following classes: (all exist within same namespace of
'company')
There are 3 separate xsd's
(person/employee/customer- people.xsd)
(manager - people-core.xsd)
(branchmanager - people-retail.xsd)

Person (fields: name,age)
^-Employee (fields: employeeID,salary) ^- Customer (fields: custID,revenue)
    ^-Manager (fields: managementGroup)
     ^-BranchManager (fields: branchID)

When I try to refer to 'salary' from within the BranchManager it claims
that it does not exist.

eg.
         <AttributeMapping>
           <targetAttribute>company:branchID</targetAttribute>
           <sourceExpression>
             <OCQL>pemb_brid</OCQL>
           </sourceExpression>
         </AttributeMapping>

         <AttributeMapping>
           <targetAttribute>company:salary</targetAttribute>
           <sourceExpression>
             <OCQL>pe_salary</OCQL>
           </sourceExpression>
         </AttributeMapping>

The DB table for branchManager has that field as expected.

Of course from the 'Employee' app-schema I can refer to it just fine
using 'company:salary'.

What am I missing ?

The XSD's specify the substitution groups ok, (example below of 'employee')

  <complexType name="EmployeeType">
         <complexContent>
             <extension base="company:PersonType">

Have attached full xsds.

The targetTypes schemaUri is set to the correct one for 'branchManager'
(people-retail.xsd) that has an 'include' to the core people.xsd

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Hello Ben,

I managed to get it working, thanks for your quick reply on this.

I’m now trying to generalise this simple use case into my more complex model, with more complex types, and frustratingly I’m getting a new set of errors:

java.lang.RuntimeException: Error applying mapping with targetAttribute comcomp:otherVar Error applying mapping with targetAttribute comcomp:otherVar comcomp otherVar is not a valid location path for type http://www.x.com/comcomp/1.0:BranchManagerType. comcomp:otherVar ns: http://www.x.com/comcomp/1.0, BranchManagerType properties: null#FEATURE_LINK, http://www.x.com/comcomp/1.0#branchManagerType

Since this ended up working fine in my simpler model i’m going to redo my more complex one, in the hope that it does fix the issue.

… but if you have any quick suggestions on what these errors mean, then I’d be very appreciative to hear them.

Thanks

···

On 2 October 2013 19:36, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Please send us the full error message that you get (include a stack trace from the logs if you have one), and your mapping file.

Your schemas look good. Good job using FullMoon to generate them!

Kind regards,
Ben.

On 02/10/13 15:44, snuffy wrote:

Hello,

I was playing around with app-schema and trying to do inheritance.

I’ve got the following classes: (all exist within same namespace of
‘company’)
There are 3 separate xsd’s
(person/employee/customer- people.xsd)
(manager - people-core.xsd)
(branchmanager - people-retail.xsd)

Person (fields: name,age)
^-Employee (fields: employeeID,salary) ^- Customer (fields: custID,revenue)
^-Manager (fields: managementGroup)
^-BranchManager (fields: branchID)

When I try to refer to ‘salary’ from within the BranchManager it claims
that it does not exist.

eg.

company:branchID

pemb_brid

company:salary pe_salary

The DB table for branchManager has that field as expected.

Of course from the ‘Employee’ app-schema I can refer to it just fine
using ‘company:salary’.

What am I missing ?

The XSD’s specify the substitution groups ok, (example below of ‘employee’)

Have attached full xsds.

The targetTypes schemaUri is set to the correct one for ‘branchManager’
(people-retail.xsd) that has an ‘include’ to the core people.xsd


October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

This error means that comcomp:BranchManagerType does not have a property comcomp:otherVar so it cannot be used in a xpath (that is why it referring to "location path"). targetAttribute is in general an xpath.

Kind regards,
Ben.

On 04/10/13 11:04, snuffy wrote:

Hello Ben,

I managed to get it working, thanks for your quick reply on this.

I'm now trying to generalise this simple use case into my more complex
model, with more complex types, and frustratingly I'm getting a new set
of errors:

java.lang.RuntimeException: Error applying mapping with targetAttribute
comcomp:otherVar Error applying mapping with targetAttribute
comcomp:otherVarcomcompotherVar is not a valid location path for type
http://www.x.com/comcomp/1.0:BranchManagerType. comcomp:otherVar ns:
http://www.x.com/comcomp/1.0, BranchManagerType properties:
null#FEATURE_LINK, http://www.x.com/comcomp/1.0#branchManagerType

Since this ended up working fine in my simpler model i'm going to redo
my more complex one, in the hope that it does fix the issue.

... but if you have any quick suggestions on what these errors mean,
then I'd be very appreciative to hear them.

Thanks

On 2 October 2013 19:36, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com
<mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

    Please send us the full error message that you get (include a stack
    trace from the logs if you have one), and your mapping file.

    Your schemas look good. Good job using FullMoon to generate them!

    Kind regards,
    Ben.

    On 02/10/13 15:44, snuffy wrote:

        Hello,

        I was playing around with app-schema and trying to do inheritance.

        I've got the following classes: (all exist within same namespace of
        'company')
        There are 3 separate xsd's
        (person/employee/customer- people.xsd)
        (manager - people-core.xsd)
        (branchmanager - people-retail.xsd)

        Person (fields: name,age)
        ^-Employee (fields: employeeID,salary) ^- Customer (fields:
        custID,revenue)
             ^-Manager (fields: managementGroup)
              ^-BranchManager (fields: branchID)

        When I try to refer to 'salary' from within the BranchManager it
        claims
        that it does not exist.

        eg.
                  <AttributeMapping>
                    <targetAttribute>company:__branchID</targetAttribute>
                    <sourceExpression>
                      <OCQL>pemb_brid</OCQL>
                    </sourceExpression>
                  </AttributeMapping>

                  <AttributeMapping>
                    <targetAttribute>company:__salary</targetAttribute>
                    <sourceExpression>
                      <OCQL>pe_salary</OCQL>
                    </sourceExpression>
                  </AttributeMapping>

        The DB table for branchManager has that field as expected.

        Of course from the 'Employee' app-schema I can refer to it just fine
        using 'company:salary'.

        What am I missing ?

        The XSD's specify the substitution groups ok, (example below of
        'employee')

           <complexType name="EmployeeType">
                  <complexContent>
                      <extension base="company:PersonType">

        Have attached full xsds.

        The targetTypes schemaUri is set to the correct one for
        'branchManager'
        (people-retail.xsd) that has an 'include' to the core people.xsd

        ------------------------------__------------------------------__------------------
        October Webinars: Code for Performance
        Free Intel webinars can help you accelerate application performance.
        Explore tips for MPI, OpenMP, advanced profiling, and more. Get
        the most from
        the latest Intel processors and coprocessors. See abstracts and
        register >
        http://pubads.g.doubleclick.__net/gampad/clk?id=60134791&iu=__/4140/ostg.clktrk

        _________________________________________________
        Geoserver-users mailing list
        Geoserver-users@anonymised.com
        https://lists.sourceforge.net/__lists/listinfo/geoserver-users

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Please keep discussions on list.

I am not sure; I speculate that this is used for multivalued properties or denormalised tables (in the absence of joining). Perhaps Rini can explain?

Kind regards,
Ben.

On 10/10/13 11:59, snuffy wrote:

Hello Ben,

Was hoping you could explain why app-schema does the following to the
database.

I have zero issue with the joins, what I do have an issue with is this
seemly tacked on the end ASC, "v_super_class"."sub_id".

I do not understand why it is required, now because i'm using postgreSQL
inheritance for my tables I was forced to create a view that satisfied
this additional requirement.

Below is query:

SELECT
"v_super_class"."sup_id","v_super_class"."sup_metadata_id","v_super_class"."sup_f_contains","v_super_class"."sub_id","sub_class"."sub_id"
FOREIGN_ID_0_0 FROM "v_super_class" INNER JOIN "sub_class" ON (
"sub_class"."sup_f_contains" = "v_super_class"."sup_f_contains") ORDER
BY "sub_class"."sub_id" ASC, "v_super_class"."sup_id" ASC, CASE WHEN
"sub_class"."sup_f_contains" = "v_super_class"."sup_f_contains" THEN 0
ELSE 1 END ASC, "v_super_class"."sub_id"

On 4 October 2013 14:55, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com
<mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

    This error means that comcomp:BranchManagerType does not have a
    property comcomp:otherVar so it cannot be used in a xpath (that is
    why it referring to "location path"). targetAttribute is in general
    an xpath.

    Kind regards,
    Ben.

    On 04/10/13 11:04, snuffy wrote:

        Hello Ben,

        I managed to get it working, thanks for your quick reply on this.

        I'm now trying to generalise this simple use case into my more
        complex
        model, with more complex types, and frustratingly I'm getting a
        new set
        of errors:

        java.lang.RuntimeException: Error applying mapping with
        targetAttribute
        comcomp:otherVar Error applying mapping with targetAttribute
        comcomp:__otherVarcomcompotherVar is not a valid location path
        for type

        http://www.x.com/comcomp/1.0:__BranchManagerType
        <http://www.x.com/comcomp/1.0:BranchManagerType&gt;\.
        comcomp:otherVar ns:
        http://www.x.com/comcomp/1.0, BranchManagerType properties:
        null#FEATURE_LINK,
        http://www.x.com/comcomp/1.0#__branchManagerType
        <http://www.x.com/comcomp/1.0#branchManagerType&gt;

        Since this ended up working fine in my simpler model i'm going
        to redo
        my more complex one, in the hope that it does fix the issue.

        ... but if you have any quick suggestions on what these errors mean,
        then I'd be very appreciative to hear them.

        Thanks

        On 2 October 2013 19:36, Ben Caradoc-Davies
        <Ben.Caradoc-Davies@anonymised.com
        <mailto:Ben.Caradoc-Davies@anonymised.com
        <mailto:Ben.Caradoc-Davies@anonymised.com>>> wrote:

             Please send us the full error message that you get (include
        a stack
             trace from the logs if you have one), and your mapping file.

             Your schemas look good. Good job using FullMoon to generate
        them!

             Kind regards,
             Ben.

             On 02/10/13 15:44, snuffy wrote:

                 Hello,

                 I was playing around with app-schema and trying to do
        inheritance.

                 I've got the following classes: (all exist within same
        namespace of
                 'company')
                 There are 3 separate xsd's
                 (person/employee/customer- people.xsd)
                 (manager - people-core.xsd)
                 (branchmanager - people-retail.xsd)

                 Person (fields: name,age)
                 ^-Employee (fields: employeeID,salary) ^- Customer
        (fields:
                 custID,revenue)
                      ^-Manager (fields: managementGroup)
                       ^-BranchManager (fields: branchID)

                 When I try to refer to 'salary' from within the
        BranchManager it
                 claims
                 that it does not exist.

                 eg.
                           <AttributeMapping>

        <targetAttribute>company:____branchID</targetAttribute>

                             <sourceExpression>
                               <OCQL>pemb_brid</OCQL>
                             </sourceExpression>
                           </AttributeMapping>

                           <AttributeMapping>

        <targetAttribute>company:____salary</targetAttribute>

                             <sourceExpression>
                               <OCQL>pe_salary</OCQL>
                             </sourceExpression>
                           </AttributeMapping>

                 The DB table for branchManager has that field as expected.

                 Of course from the 'Employee' app-schema I can refer to
        it just fine
                 using 'company:salary'.

                 What am I missing ?

                 The XSD's specify the substitution groups ok, (example
        below of
                 'employee')

                    <complexType name="EmployeeType">
                           <complexContent>
                               <extension base="company:PersonType">

                 Have attached full xsds.

                 The targetTypes schemaUri is set to the correct one for
                 'branchManager'
                 (people-retail.xsd) that has an 'include' to the core
        people.xsd

        ------------------------------____----------------------------__--__------------------

                 October Webinars: Code for Performance
                 Free Intel webinars can help you accelerate application
        performance.
                 Explore tips for MPI, OpenMP, advanced profiling, and
        more. Get
                 the most from
                 the latest Intel processors and coprocessors. See
        abstracts and
                 register >
        http://pubads.g.doubleclick.____net/gampad/clk?id=60134791&iu=____/4140/ostg.clktrk

                 ___________________________________________________
                 Geoserver-users mailing list
                 Geoserver-users@anonymised.com
        <http://sourceforge.net>
        https://lists.sourceforge.net/____lists/listinfo/geoserver-__users
        <https://lists.sourceforge.net/__lists/listinfo/geoserver-users&gt;

             --
             Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
             Software Engineer
             CSIRO Earth Science and Resource Engineering
             Australian Resources Research Centre

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Hi,

Ben is quite right. The id ordering is used to handle multivalued properties. If idExpression is missing, it will order by primary key.
If you don't want it to select "v_super_class"."sub_id", then perhaps you can set idExpression to map to another column.
http://docs.geoserver.org/latest/en/user/data/app-schema/mapping-file.html#idexpression-optional

Rini

-----Original Message-----
From: Caradoc-Davies, Ben (CESRE, Kensington)
Sent: Thursday, 10 October 2013 12:50 PM
To: snuffy
Cc: geoserver-users@lists.sourceforge.net; Angreani, Rini (CESRE, Kensington)
Subject: Re: [Geoserver-users] App-Schema: Inheritance question

Please keep discussions on list.

I am not sure; I speculate that this is used for multivalued properties or denormalised tables (in the absence of joining). Perhaps Rini can explain?

Kind regards,
Ben.

On 10/10/13 11:59, snuffy wrote:

Hello Ben,

Was hoping you could explain why app-schema does the following to the
database.

I have zero issue with the joins, what I do have an issue with is this
seemly tacked on the end ASC, "v_super_class"."sub_id".

I do not understand why it is required, now because i'm using
postgreSQL inheritance for my tables I was forced to create a view
that satisfied this additional requirement.

Below is query:

SELECT
"v_super_class"."sup_id","v_super_class"."sup_metadata_id","v_super_class"."sup_f_contains","v_super_class"."sub_id","sub_class"."sub_id"
FOREIGN_ID_0_0 FROM "v_super_class" INNER JOIN "sub_class" ON (
"sub_class"."sup_f_contains" = "v_super_class"."sup_f_contains")
ORDER BY "sub_class"."sub_id" ASC, "v_super_class"."sup_id" ASC, CASE
WHEN "sub_class"."sup_f_contains" = "v_super_class"."sup_f_contains"
THEN 0 ELSE 1 END ASC, "v_super_class"."sub_id"

On 4 October 2013 14:55, Ben Caradoc-Davies
<Ben.Caradoc-Davies@...367... <mailto:Ben.Caradoc-Davies@…367…>> wrote:

    This error means that comcomp:BranchManagerType does not have a
    property comcomp:otherVar so it cannot be used in a xpath (that is
    why it referring to "location path"). targetAttribute is in general
    an xpath.

    Kind regards,
    Ben.

    On 04/10/13 11:04, snuffy wrote:

        Hello Ben,

        I managed to get it working, thanks for your quick reply on this.

        I'm now trying to generalise this simple use case into my more
        complex
        model, with more complex types, and frustratingly I'm getting a
        new set
        of errors:

        java.lang.RuntimeException: Error applying mapping with
        targetAttribute
        comcomp:otherVar Error applying mapping with targetAttribute
        comcomp:__otherVarcomcompotherVar is not a valid location path
        for type

        http://www.x.com/comcomp/1.0:__BranchManagerType
        <http://www.x.com/comcomp/1.0:BranchManagerType&gt;\.
        comcomp:otherVar ns:
        http://www.x.com/comcomp/1.0, BranchManagerType properties:
        null#FEATURE_LINK,
        http://www.x.com/comcomp/1.0#__branchManagerType
        <http://www.x.com/comcomp/1.0#branchManagerType&gt;

        Since this ended up working fine in my simpler model i'm going
        to redo
        my more complex one, in the hope that it does fix the issue.

        ... but if you have any quick suggestions on what these errors mean,
        then I'd be very appreciative to hear them.

        Thanks

        On 2 October 2013 19:36, Ben Caradoc-Davies
        <Ben.Caradoc-Davies@...367...
        <mailto:Ben.Caradoc-Davies@…5912…
        <mailto:Ben.Caradoc-Davies@…367…>>> wrote:

             Please send us the full error message that you get (include
        a stack
             trace from the logs if you have one), and your mapping file.

             Your schemas look good. Good job using FullMoon to generate
        them!

             Kind regards,
             Ben.

             On 02/10/13 15:44, snuffy wrote:

                 Hello,

                 I was playing around with app-schema and trying to do
        inheritance.

                 I've got the following classes: (all exist within same
        namespace of
                 'company')
                 There are 3 separate xsd's
                 (person/employee/customer- people.xsd)
                 (manager - people-core.xsd)
                 (branchmanager - people-retail.xsd)

                 Person (fields: name,age)
                 ^-Employee (fields: employeeID,salary) ^- Customer
        (fields:
                 custID,revenue)
                      ^-Manager (fields: managementGroup)
                       ^-BranchManager (fields: branchID)

                 When I try to refer to 'salary' from within the
        BranchManager it
                 claims
                 that it does not exist.

                 eg.
                           <AttributeMapping>

        <targetAttribute>company:____branchID</targetAttribute>

                             <sourceExpression>
                               <OCQL>pemb_brid</OCQL>
                             </sourceExpression>
                           </AttributeMapping>

                           <AttributeMapping>

        <targetAttribute>company:____salary</targetAttribute>

                             <sourceExpression>
                               <OCQL>pe_salary</OCQL>
                             </sourceExpression>
                           </AttributeMapping>

                 The DB table for branchManager has that field as expected.

                 Of course from the 'Employee' app-schema I can refer to
        it just fine
                 using 'company:salary'.

                 What am I missing ?

                 The XSD's specify the substitution groups ok, (example
        below of
                 'employee')

                    <complexType name="EmployeeType">
                           <complexContent>
                               <extension base="company:PersonType">

                 Have attached full xsds.

                 The targetTypes schemaUri is set to the correct one for
                 'branchManager'
                 (people-retail.xsd) that has an 'include' to the core
        people.xsd

------------------------------____----------------------------__--__--
----------------

                 October Webinars: Code for Performance
                 Free Intel webinars can help you accelerate application
        performance.
                 Explore tips for MPI, OpenMP, advanced profiling, and
        more. Get
                 the most from
                 the latest Intel processors and coprocessors. See
        abstracts and
                 register >
        
http://pubads.g.doubleclick.____net/gampad/clk?id=60134791&iu=____/414
0/ostg.clktrk

                 ___________________________________________________
                 Geoserver-users mailing list
                 Geoserver-users@...5913...
        <http://sourceforge.net>
        https://lists.sourceforge.net/____lists/listinfo/geoserver-__users
        
<https://lists.sourceforge.net/__lists/listinfo/geoserver-users&gt;

             --
             Ben Caradoc-Davies <Ben.Caradoc-Davies@...367...>
             Software Engineer
             CSIRO Earth Science and Resource Engineering
             Australian Resources Research Centre

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@...367...>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...367...> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre

Hello Rini,

I’m still not quite understanding,

Why should the class being linked to have the ID field name of the class being linked from as part of its sorting?

I agree there should be sorting on the main class by its ID, but it seems wrong to require that same field to exist in the table its linking to.

I could understand if it decided to sort the linked class via its own ‘id field’ but that’s not what it does.

···

On 10 October 2013 16:19, <Rini.Angreani@anonymised.com> wrote:

Hi,

Ben is quite right. The id ordering is used to handle multivalued properties. If idExpression is missing, it will order by primary key.
If you don’t want it to select “v_super_class”.“sub_id”, then perhaps you can set idExpression to map to another column.
http://docs.geoserver.org/latest/en/user/data/app-schema/mapping-file.html#idexpression-optional

Rini

-----Original Message-----
From: Caradoc-Davies, Ben (CESRE, Kensington)
Sent: Thursday, 10 October 2013 12:50 PM
To: snuffy
Cc: geoserver-users@lists.sourceforge.net; Angreani, Rini (CESRE, Kensington)
Subject: Re: [Geoserver-users] App-Schema: Inheritance question

Please keep discussions on list.

I am not sure; I speculate that this is used for multivalued properties or denormalised tables (in the absence of joining). Perhaps Rini can explain?

Kind regards,
Ben.

On 10/10/13 11:59, snuffy wrote:

Hello Ben,

Was hoping you could explain why app-schema does the following to the
database.

I have zero issue with the joins, what I do have an issue with is this
seemly tacked on the end ASC, “v_super_class”.“sub_id”.

I do not understand why it is required, now because i’m using
postgreSQL inheritance for my tables I was forced to create a view
that satisfied this additional requirement.

Below is query:

SELECT
“v_super_class”.“sup_id”,“v_super_class”.“sup_metadata_id”,“v_super_class”.“sup_f_contains”,“v_super_class”.“sub_id”,“sub_class”.“sub_id”
FOREIGN_ID_0_0 FROM “v_super_class” INNER JOIN “sub_class” ON (
“sub_class”.“sup_f_contains” = “v_super_class”.“sup_f_contains”)
ORDER BY “sub_class”.“sub_id” ASC, “v_super_class”.“sup_id” ASC, CASE
WHEN “sub_class”.“sup_f_contains” = “v_super_class”.“sup_f_contains”
THEN 0 ELSE 1 END ASC, “v_super_class”.“sub_id”

On 4 October 2013 14:55, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com mailto:[Ben.Caradoc-Davies@anonymised.com](mailto:Ben.Caradoc-Davies@anonymised.com)> wrote:

This error means that comcomp:BranchManagerType does not have a
property comcomp:otherVar so it cannot be used in a xpath (that is
why it referring to “location path”). targetAttribute is in general
an xpath.

Kind regards,
Ben.

On 04/10/13 11:04, snuffy wrote:

Hello Ben,

I managed to get it working, thanks for your quick reply on this.

I’m now trying to generalise this simple use case into my more
complex
model, with more complex types, and frustratingly I’m getting a
new set
of errors:

java.lang.RuntimeException: Error applying mapping with
targetAttribute
comcomp:otherVar Error applying mapping with targetAttribute
comcomp:__otherVarcomcompotherVar is not a valid location path
for type

http://www.x.com/comcomp/1.0:__BranchManagerType
<http://www.x.com/comcomp/1.0:BranchManagerType>.
comcomp:otherVar ns:
http://www.x.com/comcomp/1.0, BranchManagerType properties:
null#FEATURE_LINK,
http://www.x.com/comcomp/1.0#__branchManagerType
<http://www.x.com/comcomp/1.0#branchManagerType>

Since this ended up working fine in my simpler model i’m going
to redo
my more complex one, in the hope that it does fix the issue.

… but if you have any quick suggestions on what these errors mean,
then I’d be very appreciative to hear them.

Thanks

On 2 October 2013 19:36, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com
<mailto:Ben.Caradoc-Davies@__csiro.au
mailto:[Ben.Caradoc-Davies@anonymised.com](mailto:Ben.Caradoc-Davies@anonymised.com...)>> wrote:

Please send us the full error message that you get (include
a stack
trace from the logs if you have one), and your mapping file.

Your schemas look good. Good job using FullMoon to generate
them!

Kind regards,
Ben.

On 02/10/13 15:44, snuffy wrote:

Hello,

I was playing around with app-schema and trying to do
inheritance.

I’ve got the following classes: (all exist within same
namespace of
‘company’)
There are 3 separate xsd’s
(person/employee/customer- people.xsd)
(manager - people-core.xsd)
(branchmanager - people-retail.xsd)

Person (fields: name,age)
^-Employee (fields: employeeID,salary) ^- Customer
(fields:
custID,revenue)
^-Manager (fields: managementGroup)
^-BranchManager (fields: branchID)

When I try to refer to ‘salary’ from within the
BranchManager it
claims
that it does not exist.

eg.

company:____branchID

pemb_brid

company:____salary

pe_salary

The DB table for branchManager has that field as expected.

Of course from the ‘Employee’ app-schema I can refer to
it just fine
using ‘company:salary’.

What am I missing ?

The XSD’s specify the substitution groups ok, (example
below of
‘employee’)

Have attached full xsds.

The targetTypes schemaUri is set to the correct one for
‘branchManager’
(people-retail.xsd) that has an ‘include’ to the core
people.xsd

------------------------------____----------------------------

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application
performance.
Explore tips for MPI, OpenMP, advanced profiling, and
more. Get
the most from
the latest Intel processors and coprocessors. See
abstracts and
register >

http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/414
0/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsource__forge.net
<http://sourceforge.net>
https://lists.sourceforge.net/____lists/listinfo/geoserver-__users

<https://lists.sourceforge.net/__lists/listinfo/geoserver-users>


Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com…367…>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre

Hi snuffy,

The joining work is legacy of Niels Charlier during his time with our
organisation, so I may not be 100% correct.

From my understanding, this is because the same rows from the linked table

could be chained by multiple parents from the main table. Therefore the
parent id is needed as foreign key to distinguish the parents.

e.g.

super class id| joining condition

1 | x
2 | y
3 | x
4 | z

sub class id | joining condition

a | x
b | y
c | z

Row 1 and 3 in the super class matches the same sub class rows (sub class id
= a).
Joining generates the following result set using INNER JOIN:

sub class id | joining condition | super class id

a | x | 1
a | x | 3
b | y | 2
c | z | 4

Joining relies heavily on sorting so it doesn't have to run so many queries.
The super class id here is used to signal when to stop building the chained
feature for the parent.
I hope that makes sense.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/App-Schema-Inheritance-question-tp5081362p5083567.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

That is correct.

Regards
Niels

On 15/10/13 06:16, Rini Angreani wrote:

Hi snuffy,

The joining work is legacy of Niels Charlier during his time with our
organisation, so I may not be 100% correct.
>From my understanding, this is because the same rows from the linked table
could be chained by multiple parents from the main table. Therefore the
parent id is needed as foreign key to distinguish the parents.

e.g.

super class id| joining condition

1 | x
2 | y
3 | x
4 | z
  sub class id | joining condition

a | x
b | y
c | z

Row 1 and 3 in the super class matches the same sub class rows (sub class id
= a).
Joining generates the following result set using INNER JOIN:

sub class id | joining condition | super class id

a | x | 1
a | x | 3
b | y | 2
c | z | 4

Joining relies heavily on sorting so it doesn't have to run so many queries.
The super class id here is used to signal when to stop building the chained
feature for the parent.
I hope that makes sense.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/App-Schema-Inheritance-question-tp5081362p5083567.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users