Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I'm having trouble referencing camel cased db columns? #389

Closed
nickMAP opened this issue Aug 31, 2022 · 4 comments · Fixed by #380
Closed

I'm having trouble referencing camel cased db columns? #389

nickMAP opened this issue Aug 31, 2022 · 4 comments · Fixed by #380

Comments

@nickMAP
Copy link

nickMAP commented Aug 31, 2022

I need help or an example on how to configure the settings for camelCased geometry columns. If I use a camel-column, I get the following error.

ERROR martin::server] Can't get composite source tile: db error: ERROR: column "someCamelCasedColumn" does not exist

The column does exist and I have verified that other tile server programs and database visualizers are able to display the associated polygons. Furthermore, the column is detected when martin scans the database.

 # Geometry column name (required)
    geometry_column: someCamelCasedColumn 
@nickMAP
Copy link
Author

nickMAP commented Aug 31, 2022

I tried to follow this example from the docs...

In case if you have multiple geometry columns in that table and want to access a particular geometry column in vector tile, you should also specify the geometry column in the table source name

curl localhost:3000/public.points.geom/0/0/0.pbf

but if I use

curl localhost:3000/public.points.somCamelCasedColumn/0/0/0.pbf I will get the err.

@nyurik
Copy link
Member

nyurik commented Sep 1, 2022

there must be a bug in matching config to what was auto-discovered. Should be an easy bug to fix (i haven't yet confirmed this is a real bug)

@sharkAndshark
Copy link
Collaborator

Pg is case sensitive. See doc 4.1.1
Unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other.

@nyurik
Copy link
Member

nyurik commented Dec 6, 2022

I think this is a bigger issue than I first thought, and we may need to figure out the "proper" (least surprising) way to handle it. Here's an example of a table that breaks every possible "good design principle" rules. The schema, table, index, and fields all use mixed cases or keywords. On top of it, it also creates two tables that only differ in table name case, and multiple identical field names.

I think the best matching algorithm would be this:

  • always use a query to get all available schemas/tables/functions/fields. Store them as a hashmap of hashmap structure.
  • first try to find the exact match as provided by configuration.
  • if not found, iterate over all keys, matching them in a case-insensitive manner. If multiple were found, give a warning and don't use it (better to error early than to use an incorrect one)
DROP SCHEMA IF EXISTS "MixedCase" CASCADE;
CREATE SCHEMA "MixedCase";

CREATE TABLE "MixedCase"."PoiNTs3"("Gid" SERIAL PRIMARY KEY, "TABLE" TEXT, "table" INT, "Geom" GEOMETRY(POINT, 4326));
CREATE TABLE "MixedCase"."Points3"("Gid" SERIAL PRIMARY KEY, "TABLE" TEXT, "Geom" GEOMETRY(POINT, 4326));

INSERT INTO "MixedCase"."Points3"
    SELECT
        generate_series(1, 10000) as id,
        md5(random()::text) as "TABLE",
        (
            ST_DUMP(ST_GENERATEPOINTS(ST_GEOMFROMTEXT('POLYGON ((-180 90, 180 90, 180 -90, -180 -90, -180 90))', 4326), 10000))
        ).Geom;

CREATE INDEX ON "MixedCase"."Points3" USING GIST("Geom");
CLUSTER "MixedCase"."Points3" USING "Points3_Geom_idx";

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants