Problems setting up a new search

[mtravis]

Hi Tobin

Firstly, thanks for another great project! It's going to be really useful.

I've set up an API running from here: http://maps.moorthanmeetstheeye.org/api/documentation

It seems to be working fine apart from the search.

I've edited config/index.js to include this search:

mons: {
      table: 'monument_point',
      columns: `name`,
      where: `name ilike ?`,
      format: function(query) { return '%' + query.trim() + '%'; } 
    }

When I try use the search tool on the docs page I get this error.

I've tried changing the table to monument_point (the actual table as its know in the database) but that just gives me a 500 error? Where am I going wrong?

Cheers

Matt

[tobinbradley]

If you look at the top of index.js in config, scrunched in the comments in my usual unhelpful/vague way is this:

// Each search must return the fields id, label, type, lng, lat, pid, and address.

But that's actually wrong. Search does a union of all the search tables in the request, so for the most part the fields returned in each search only have to match each other, and they really only have to match each other for multiple tables searched in one query.

Except...the way it's set up you do need to return the columns type and label, because it does an order SQL clause with those. With the one return column you have specified now the SQL it creates looks like this:

(SELECT name FROM monument_point WHERE (name ilike '%test%') LIMIT 10) order by type, label

Since there aren't type or label columns in your query, it's dying on the last bit. If you change your config to something like:

mons: {
      table: 'monument_point',
      columns: `name as label, 'monuments' as type`,
      where: `name ilike ?`,
      format: function(query) { return '%' + query.trim() + '%'; } 
    }

That should work. I think.

Sorry - I'll tighten up the documentation in index.js. My documentation is usually either vague or incorrect, but I managed to score both on this one :).

[mtravis]

Thanks for getting back so quickly. I somehow missed the glaringly obvious comments at the top there :)

I tried changing the config to what you suggested but that didn't work so I've tried to be more explicit and use this:

mons: {
      table: 'monument_point',
      columns: `ogc_fid as pid, monuid as label, montype as type, round(ST_X(ST_Transform(wkb_geometry, 4326))::NUMERIC,4) as lng, round(ST_Y(ST_Transform(wkb_geometry,4326))::NUMERIC,4) as lat, name as address`,
      where: `name ilike ?`,
      format: function(query) { return '%' + query.trim() + '%'; } 
    }

Should that work. It doesn't at present?

[tobinbradley]

Hmm...

Does your client login have select access to the table? Are you sure you're not looking at a cached result?

I just made a table called monuments_point -

CREATE TABLE monuments_point
(
  code character(5) NOT NULL,
  name character varying(40) NOT NULL,
  CONSTRAINT firstkey PRIMARY KEY (code)
)
WITH (
  OIDS=FALSE
);

• threw a single record in it with a name value of 'test', set up the config this way -

mons: {
      table: 'monuments_point',
      columns: `name as label, 'monuments' as type`,
      where: `name ilike ?`,
      format: function(query) { return '%' + query.trim() + '%'; }
    }

• and darn if it didn't work -

By default the results are caching in the browser, so try changing the limit value to make it run a new query or launch it in private browsing mode.

[mtravis]

​I've just realised that I'm running this through a proxy.
The main site is apache (all on the same server) and I've added a proxypass to point to the location of the dirt-simple app.

Would this affect it?

Cheers

Matt​

On Fri, Apr 22, 2016 at 4:09 PM, Tobin Bradley notifications@github.com
wrote:

Hmm...

Does your client login have select access to the table? Are you sure
you're not looking at a cached result?

I just made a table called monuments_point -

CREATE TABLE monuments_point
(
code character(5) NOT NULL,
name character varying(40) NOT NULL,
CONSTRAINT firstkey PRIMARY KEY (code)
)
WITH (
OIDS=FALSE
);

• threw a single record in it with a name value of 'test', set up the
  config this way -

mons: {
table: 'monuments_point',
columns: name as label, 'monuments' as type,
where: name ilike ?,
format: function(query) { return '%' + query.trim() + '%'; }
}

• and darn if it didn't work -

[image: Imgur]
https://camo.githubusercontent.com/8d5a4c7b3eeaaabe71d237d697c816edab0b404b/687474703a2f2f692e696d6775722e636f6d2f415a4d646131672e706e67

By default the results are caching in the browser, so try changing the
limit value to make it run a new query or launch it in private browsing
mode.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2 (comment)

[tobinbradley]

Nope. Mecklenburg does the same thing. You can have other Apache rules changing incoming requests in any number of breaking ways, but that would most likely manifest itself as a 404.

You could stick a console.log(sql) in the fetch to see what SQL call is being sent and try to run it straight at your DB to see what happens.

[mtravis]

Ok great. I'll give that a go and let you know how I get on.
On 22 Apr 2016 5:04 p.m., "Tobin Bradley" notifications@github.com wrote:

Nope. Mecklenburg does the same thing. You can have other Apache rules
changing incoming requests in any number of breaking ways, but that would
most likely manifest itself as a 404.

You could stick a console.log(sql) in the fetch to see what SQL call is
being sent and try to run it straight at your DB to see what happens.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2 (comment)

[mtravis]

I think I've made a bit of a school boy error here. After adding console.log(sql) to the fetch function I realised that at no point I had tried restarting the node app.

I was using forever (good or bad idea? ) and thought that I could make changes to config without restarting. Maybe I'm getting confused with gulp.

Anyhow, got it working now so all's good in the hood.

Thanks and massive props for the awesome app!

[tobinbradley]

No worries! Glad it got sorted.

forever is good. forever has a watch option that restarts the server on file change. You can use it like:

forever --watch --watchDirectory ./path/to/dir ./start/file

The hip thing right now seems to be using forever in conjunction with nodemon instead, but I don't know why. Something like:

forever -c nodemon --exitcrash app.js

[mtravis]

Cool. I'll give the watch option a go.

I'll leave the nodemon combo to the hipsters!