[pgrouting-dev] PGR 2.0 - Refactored the TYPEs and Added a seq column

[Alec Gosse]

Hello,

This looks like a nice concise list of return types. 

In relation to our discussion on bulk routing, however, I was thinking that I would need to add a routeId column to the ptr_costResult type in order to return multiple routes from the same query, unless there is a function structure that I am not aware of?

Alec


On May 13, 2013, at 9:30 PM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

> Hi All,
> 
> Another big change just got pushed to the repository for sew-devel-2_0.
> 
> This change involved refactoring and abstracting our return types from our functions. Basically every function was create a new return type that was the same but a little different mostly in the column names.
> 
> So what we now have are:
> 
>    CREATE TYPE pgr_costResult AS
>    (
>        seq integer,
>        id1 integer,
>        id2 integer,
>        cost float8
>    );
> 
>    CREATE TYPE pgr_geomResult AS
>    (
>        seq integer,
>        id1 integer,
>        id2 integer,
>        geom geometry
>    );
> 
>    CREATE TYPE pgr_vertexResult AS
>    (
>        x float8,
>        y float8
>    );
> 
> and I have eliminated 6 of the old types, namely:
> 
>    pgr_pathResult
>    pgr_geoms
>    pgr_apspEdge
>    pgr_linkPoint
>    pgr_kspResult
>    pgr_kspGeoms
> 
> 
> You will also notice that I have added a seq column to the first two types and this can be used to maintain order if you need two.
> 
> So what are id1 and id2? these are just generic names, you will have to looks at the specify function to see what it returns in these slots.
> 
> The docs have NOT been updated to reflect these changes, but Daniel and I will work on this over the next few days.
> 
> CALL FOR HELP!
> 
> One of the things that we really could use some help with is building test cases. I would like to see a minimum of one test per function call and ideally one for each of the variation that a function has.
> 
> This should not be that hard to do, because we have cut down significantly on the number of functions by abandoning most of the wrapper functions. But there are still a lot of functions in the src/common/sql/ directory that have no test. When I was converting the code for the changes above, I found a bunch functions in the matching code that clearly have never worked correctly because they had assignments like:
> 
>   variable = equation;
> 
> which basic computes the boolean comparison of variable and equation and then throws away the result. Oooops! This must be written like:
> 
>   variable := equation;
> 
> to do an assignment.
> 
> Anyway having the tests that we do have made it much faster to identify problems in the code I changed and to make sure everything was working as it was before I made the changes. I'm just worried about the things we do not have test for! and should should you!
> 
> Let me know how it goes when you have a chance to give it a try.
> 
> Thanks,
>  -Steve
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev