I cannot make the CQL parameter IN work - postgresql

When using the CQL IN operator in my URL i get no result. If I use CQL_FILTER=id=229539 the URL is working fine. I really need to specify a list so i tried to use the CQL IN operator with no luck. I tried CQL_FILTER=id IN (229539) and CQL_FILTER=id IN ('229539'), both not working - why?

CQL
id IN ('229539')
should actually be fine, we have such queries and they do work.
What you could do to troubleshoot:
Make sure that URL correctly encoded. Maybe some of the quotes or brackets get interpreted incorrectly.
Make sure taht nothing else in the query interacts with your query.
Make sure you don't request two or more layers.
Turn on and look into the GeoServer logs. I can't give you the exact pointer, but it is possible to turn on the verbose logging and you'll see how the query is processed (up to SQL). This may give good hints.
If nothing helps, post your metadata (WFS GetCapabilities) and exact URLs you're trying.
You may also want to ask here.

The problem was not the CQL. The CQL was correct. The problem was the definition of the view used for the request.
CREATE OR REPLACE VIEW data.yellowgreen AS
SELECT
markblok.id AS id,
temp_kvadrats.value,
st_intersection(markblok.geom, temp_kvadrats.geom) AS geom,
temp_kvadrats.session_id
FROM data.temp_kvadrats
JOIN data.markblok ON st_intersects(markblok.geom, temp_kvadrats.geom);
The CQL only works with 'markblok.id AS id' and not with just 'markblok.id', eventhough a list of the view names the column shows id in both cases.

Related

How can I filter the contents in the TABLE panel?

So is there a way to filter what Grafana shows in a TABLE type of metric?
My issue is that the table returns values which are really really long like a FQDN but for an Azure resource.
It is absolutely unreadable, so I actually want to parse the output with regex or something, to show me only the specific part. At least a line break would suffice.
The row field in the table is something like
azure:///subscriptions/xxxxxxxxxx-4a5b-81ee-04ea1368a7db/resourceGroups/mc_wintermute_wintermute_eastus/providers/Microsoft.Compute/virtualMachineScaleSets/axxxxxxxxvmss/virtualMachines/13
I only need the
subscriptions/xxxxxxxxxx-4a5b-81ee-04ea1368a7db/
It is easier to view it than explain, a
screenshot
Apparently, there is a VALUE MAPPING section in the table parameters, which accepts regular expressions.

Access Form - Syntax error (missing operator) in query expression

I am receiving a syntax error in a form that I have created over a query. I created the form to restrict access to changing records. While trying to set filters on the form, I receive syntax errors for all attributes I try to filter on. I believe this has something to do with the lack of () around the inner join within the query code, but what is odd to me is that I can filter the query with no problem. Below is the query code:
SELECT CUSTOMER.[Product Number], SALESPERSON.[Salesperson Number],
SALESPERSON.[Salesperson Name], SALESPERSON.[Email Address]
FROM SALESPERSON INNER JOIN CUSTOMER ON
SALESPERSON.[Salesperson Number] = CUSTOMER.[Salesperson Number];
Any ideas why only the form would generate the syntax error, or how to fix this?
I was able to quickly fix it by going into Design View of the Form and putting [] around any field names that had spaces. I am now able to use the built in filters without the annoying popup about syntax problems.
I had this same problem.
As Dedren says, the problem is not the query, but the form object's control source. Put [] around each objects Control Source. eg: Contol Source: [Product number], Control Source: Salesperson.[Salesperson number], etc.
Makita recomends going to the original table that you are referencing in your query and rename the field so that there are no spaces eg: SalesPersonNumber, ProductNumber, etc. This will solve many future problems as well. Best of Luck!
Try making the field names legal by removing spaces. It's a long shot but it has actually helped me before.
No, no, no.
These answers are all wrong. There is a fundamental absence of knowledge in your brain that I'm going to remedy right now.
Your major issue here is your naming scheme. It's verbose, contains undesirable characters, and is horribly inconsistent.
First: A table that is called Salesperson does not need to have each field in the table called Salesperson.Salesperson number, Salesperson.Salesperson email. You're already in the table Salesperson. Everything in this table relates to Salesperson. You don't have to keep saying it.
Instead use ID, Email. Don't use Number because that's probably a reserved word. Do you really endeavour to type [] around every field name for the lifespan of your database?
Primary keys on a table called Student can either be ID or StudentID but be consistent. Foreign keys should only be named by the table it points to followed by ID. For example: Student.ID and Appointment.StudentID. ID is always capitalized. I don't care if your IDE tells you not to because everywhere but your IDE will be ID. Even Access likes ID.
Second: Name all your fields without spaces or special characters and keep them as short as possible and if they conflict with a reserved word, find another word.
Instead of: phone number use PhoneNumber or even better, simply, Phone. If you choose what time user made the withdrawal, you're going to have to type that in every single time.
Third: And this one is the most important one: Always be consistent in whatever naming scheme you choose. You should be able to say, "I need the postal code from that table; its name is going to be PostalCode." You should know that without even having to look it up because you were consistent in your naming convention.
Recap: Terse, not verbose. Keep names short with no spaces, don't repeat the table name, don't use reserved words, and capitalize each word. Above all, be consistent.
I hope you take my advice. This is the right way to do it. My answer is the right one. You should be extremely pedantic with your naming scheme to the point of absolute obsession for the rest of your lives on this planet.
NOTE:You actually have to change the field name in the design view of the table and in the query.
Put [] around any field names that had spaces (as Dreden says) and save your query, close it and reopen it.
Using Access 2016, I still had the error message on new queries after I added [] around any field names... until the Query was saved.
Once the Query is saved (and visible in the Objects' List), closed and reopened, the error message disappears. This seems to be a bug from Access.
I did quickly fix it by going into "Design View" of the main Table of same Form and putting underline (_) between any field names that had spaces. I am now able to use the built in filters without the annoying popup about syntax problems.
Extra ( ) brackets may create problems in else if flow. This also creates Syntax error (missing operator) in query expression.
I had this on a form where the Recordsource is dynamic.
The Sql was fine, answer is to trap the error!
Private Sub Form_Error(DataErr As Integer, Response As Integer)
' Debug.Print DataErr
If DataErr = 3075 Then
Response = acDataErrContinue
End If
End Sub

Sphinx: JSON meta attributes stopped working

I'm currently experimenting with sphinx realtime index. I inserted 4,5 millions documents.
Everything was working OK while my json meta attributes were like this:
{"result_type":"publications","publication_type":"essay"}
But yesterday, I wanted to add another value in 'publication_type' key and the json
resulted to:
{"result_type":"publications","publication_type":["essay","big_text"]}
Now I can't find document neither for 'essay', neither for 'big_text'.
The sphinxql query I'm using is like this:
select * from url where meta.publication_type='essay';
Sphinx version is Server version: 2.1.1-beta (rel21-r3701) running on Debian.
Hope you can help me. Is my json string wrong? Where is my mistake?
Thanks in advance.
SELECT *, ANY(x='essay' FOR x IN meta.publication_type) as p FROM url WHERE p=1;
Supported in 2.2.1-dev since r4217.
This was answered on the sphinx forum:
http://sphinxsearch.com/forum/view.html?id=11486
When store arrays, you access the values by index.
So could do
select * from url where meta.publication_type[0]='essay';
It doesnt appear to easy to search 'in any position'. So if essay was ever not the first index, it wouldnt work.
Note, I can't claim credit for figuring this out, just passing this information on.

CouchDB query using :group_level and :key

I am using CouchDB 1.1.1 for my web app-- everything has worked great so far (saving/retrieving documents, saving/querying views, etc) but I am stuck on a querying a view for a particular key at a particular group level.
The map function in my view outputs keys with the following format: ["Thing 1" "Thing 2"]. I have a reduce function which works fine and outputs correct values for group level 1 (ie by "thing 1") and by group level 2 (ie by "thing 2").
Now-- when I query couchdb I CAN grab just one particular key when I set reduce = true (default), group_level=2 (or group=true, which are the same in this case since I only have 2 levels) and key = "desiredkeyhere." I can also query multiple keys with keys = ["key1" "key2"].
HOWEVER-- I really want to be able to grab a particular key for group_level=1, and I cannot get that to work. It seems to return nothing, or if use a post request, it returns everything. Never just the one key that I need.
Heres a link the the couchdb http view api (querying options) that I've been using:
http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
It contains the following sentence:
"Note: Multiple keys request to a reduce function only supports group=true and NO group_level (identical to group_level=exact). The resulting error is "Multi-key fetchs for reduce view must include group=true""
Im not sure if this means that I cannot do what I have described above (grab a particular key for a particular group_level). That would seem like a huge problem with couchdb, so Im assuming Im doing something wrong.
Any ideas? Thanks
I have hit this too. I am not sure if it is a bug, though.
Try using your startkey and endkey in the normal (2-item) format. You want a result for ["Thing 1", *] (obviously pseudocode, the star represents anything). Reducing with group_level=1 will boil all of that down to one row.
So, query basically everything in the Thing 1 "namespace," so to speak. Since the "smallest" value to collate is null and the "greatest" value is the object {}, those make good bookends for your range.
?group_level=1&startkey=["Thing 1",null]&endkey=["Thing 1",{}]
Does that give you the result you need?

Writing a query with ORMLite

How can I write a query with ormlite instead of using .create or any other thing like that? Can you please show me how for this simple example :
SELECT name FROM client
EDIT since I can't answer myself :
I guess I had to search a little more , anyway I found how to do it with the QueryBuilder like this :
newDao.query(newDao.queryBuilder().where.eq("name",valueofname)
If someone knows how to write the full query that would be great , otherwise , I'll stick with this solution
How can I write a query with ormlite instead of using .create or any other thing like that?
Goodness, there are tons of documentation about how to do this on the ORMLite site. Here's the section on the query builder.
I'm not sure what you mean by "full query" but your example will work with some tweaks:
List<...> results = newDao.queryBuilder().where().eq("name",valueofname).query();
It does not make sense to just return the name since the Dao hierarchy is designed to return the specific Client object. If you just want the name the you can specify the name column only to return:
... clientDao.queryBuilder().selectColumns("name").where()...
That will return a list of Client objects with just the name field (and the id field if it exists) extracted from the database.
If you just want the name strings then you can use the RawResults feature.