Can I use rowmode: 'array' in combination with named parameters? - pg-promise

Is it possible to have rowMode: 'array' and named parameters at the same time? Right now, with the code below, I'm getting syntax error at or near "$"
db.query({
text: `
select task_nr, commitment
from surveys
where email = $<email> and id = $<id>
order by task_nr
`,
values: {email: email, id: id},
rowMode: 'array',
})

No, it is not possible, because rowMode is strictly part of the Parameterized Query, which by definition forwards query formatting to the driver->server where such thing as Named Parameters does not exist.
Unfortunately, if you really need to use rowMode, you can only use the basic $1, $2... variable formatting as supported by the server.
Strictly speaking, rowMode is not that valuable, it is fairly easy to reformat the data, and then just use pg-promise default formatting with all its nice formatting features.

Related

Apply Command to String-type custom fields with YouTrack Rest API

and thanks for looking!
I have an instance of YouTrack with several custom fields, some of which are String-type. I'm implementing a module to create a new issue via the YouTrack REST API's PUT request, and then updating its fields with user-submitted values by applying commands. This works great---most of the time.
I know that I can apply multiple commands to an issue at the same time by concatenating them into the query string, like so:
Type Bug Priority Critical add Fix versions 5.1 tag regression
will result in
Type: Bug
Priority: Critical
Fix versions: 5.1
in their respective fields (as well as adding the regression tag). But, if I try to do the same thing with multiple String-type custom fields, then:
Foo something Example Something else Bar P0001
results in
Foo: something Example Something else Bar P0001
Example:
Bar:
The command only applies to the first field, and the rest of the query string is treated like its String value. I can apply the command individually for each field, but is there an easier way to combine these requests?
Thanks again!
This is an expected result because all string after foo is considered a value of this field, and spaces are also valid symbols for string custom fields.
If you try to apply this command via command window in the UI, you will actually see the same result.
Such a good question.
I encountered the same issue and have spent an unhealthy amount of time in frustration.
Using the command window from the YouTrack UI I noticed it leaves trailing quotations and I was unable to find anything in the documentation which discussed finalizing or identifying the end of a string value. I was also unable to find any mention of setting string field values in the command reference, grammer documentation or examples.
For my solution I am using Python with the requests and urllib modules. - Though I expect you could turn the solution to any language.
The rest API will accept explicit strings in the POST
import requests
import urllib
from collections import OrderedDict
URL = 'http://youtrack.your.address:8000/rest/issue/{issue}/execute?'.format(issue='TEST-1234')
params = OrderedDict({
'State': 'New',
'Priority': 'Critical',
'String Field': '"Message to submit"',
'Other Details': '"Fold the toilet paper to a point when you are finished."'
})
str_cmd = ' '.join(' '.join([k, v]) for k, v in params.items())
command_url = URL + urllib.urlencode({'command':str_cmd})
result = requests.post(command_url)
# The command result:
# http://youtrack.your.address:8000/rest/issue/TEST-1234/execute?command=Priority+Critical+State+New+String+Field+%22Message+to+submit%22+Other+Details+%22Fold+the+toilet+paper+to+a+point+when+you+are+finished.%22
I'm sad to see this one go unanswered for so long. - Hope this helps!
edit:
After continuing my work, I have concluded that sending all the field
updates as a single POST is marginally better for the YouTrack
server, but requires more effort than it's worth to:
1) know all fields in the Issues which are string values
2) pre-process all the string values into string literals
3) If you were to send all your field updates as a single request and just one of them was missing, failed to set, or was an unexpected value, then the entire request will fail and you potentially lose all the other information.
I wish the YouTrack documentation had some mention or discussion of
these considerations.

What's the right sintax to search for a X(6) format var in Progress 4gl?

On the statement below I have an error telling me that attribute type is not compatible with. I consult database properties and this attribute format is x(6). Does anyone know which the right sintax to get it ?
P.s. I already tried = '1', EQ 1, EQ '1', = "1" and EQ "1"
FOR EACH bd.tablename WHERE bd.tablename.attribute = "1"
When you say property/attribute, do you mean a field? If you're talking about buffer/table attributes, such as type, for example, the separator should be colon, this -> :
Not period (.), unlike most other OO languages.
But if you're talking about a field, TheMadDBA is correct, and you should check the data type, it's way safer than just the field format.
If you still have this issue, maybe provide more information and we can try to help you further.
The code statement is:
FOR EACH multipos.mp_mvlj WHERE multipos.mp_mvlj.mvl_codmov = 1 NO-LOCK:
The error is (translated from portuguese):
Incompatible Data type in expression or attribution

Query string parsing as number when it should be a string

I am trying to send a search input to a REST service. In some cases the form input is a long string of numbers (example: 1234567890000000000123456789). I am getting 500 error, and it looks like something is trying the convert the string to a number. The data type for the source database is a string.
Is there something that can be done in building the query string that will force the input to be interpreted as a string?
The service is an implementation of ArcGIS server.
More information on this issue per request.
To test, I have been using a client form provided with the service installation (see illustration below).
I have attempted to add single and double quotes, plus wildcard characters in the form entry. The form submission does not error, but no results are found. If I shorten the number("1234"), or add some alpha numeric characters ("1234A"), the form submission does not error.
The problem surfaced after a recent upgrade to 10.1. I have looked for information that would tie this to a known problem, but not found anything yet.
In terms of forcing the input to be interpreted as a string, you enclose the input in single quotes (e.g., '1234567890000000000123456789'). Though if you are querying a field of type string then you need to enclose all search strings in single quotes, and in that case none of your queries should be working. So it's a little hard to tell from the information you've provided what exactly you are doing and what might be going wrong. Can you provide more detail and/or code? Are you formatting a where clause that you are using in a Query object via one of Esri's client side API's (such as the JavaScript API)? In that case, for fields of data type string you definitely need to enclose the search text in single quotes. For example if the field you are querying were called 'FIELD', this is how you'd format the where clause:
FIELD = '1234'
or
FIELD Like '1234%'
for a wildcard search. If you are trying to enter query criteria directly into the Query form of a published ArcGIS Server service/layer, then there too you need to enclose the search in single quotes, as in the above examples.
According to an Esri help technician, this is known bug.

How to escape some characters in postgresql

I have this data in one column in postgresql
{
"geometry":{
"status":"Point",
"coordinates":[
-122.421583,
37.795027
]
},
and i using his query
select * from students where data_json LIKE '%status%' ;
Above query return results but this one does not
select * from students where data_json LIKE '%status:%' ;
How can fix that
Of course the 2nd one doesn't find a match, there's no status: text in the value. I think you wanted:
select * from students where data_json LIKE '%"status":%'
... however, like most cases where you attempt text pattern matching on structured data this is in general a terrible idea that will bite you. Just a couple of problem examples:
{
"somekey": "the value is \"status\": true"
}
... where "status": appears as part of the text value and will match even though it shouldn't, and:
{
status : "blah"
}
where status has no quotes and a space between the quotes and colon. As far as JavaScript is concerned this is the same as "status": but it won't match.
If you're trying to find fields within json or extract fields from json, do it with a json parser. PL/V8 may be of interest, or the json libraries available for tools like pl/perl, pl/pythonu, etc. Future PostgreSQL versions will have functions to get a json key by path, test if a json value exists, etc, but 9.2 does not.
At this point you might be thinking "why don't I use regular expressions". Don't go there, you do not want to try to write a full JSON parser in regex. this blog entry is somewhat relevant.

Play Framework - find Object with "Or" in the query

It is possible to use "AND" while querying for Objects in Entity like
Post.find("byTitleLikeAndAuthor", "%hello%", connectedUser).fetch();
but is it possible to user "OR" while querying, like
Post.find("byNameOrEmail", name, email).fetch();
Thank you
Fixed!!
Use Post.find(" name = ? or email ?", name, email).fetch();
While using "where" in the query, it fails saying "unexpected token"
It is indeed possible to use "And" clauses when constructing objects, but I'm not aware of a possibility in simplified query to use "Or".
However, play can be used in many ways. Instead of writing :
Post.find("byNameOrEmail", name, email).fetch();
You can write :
Post.find("name = ? or email = ?", name, email).fetch();
using JPQL syntax.
It's not possible to use simplified query with or. To enable it you must change the implementation of findByToJPQL in the class play.db.jpa.JPQL. Wrote test and enhance the documentation and create a patch.
How ever you can use the JPQL.