This shows up in our schema.rb diff sometimes, and I asked my team around and it seems they all have the same postgresql version. With a conditional index, the dumped schema sometimes look like this:
t.index ["field_name"], name: "irrelevant", unique: true,
where: "((state))::text = ANY (ARRAY[('applied'::character varying)::text]))"
and sometimes like that:
t.index ["field_name"], name: "irrelevant", unique: true,
where: "((state))::text = ANY (ARRAY['applied'::character varying]::text[]))"
so the difference seems to be only with the way the casting is expressed:
ARRAY['string'::text]
// vs
ARRAY['string']::text[]
It seems to me those two castings are equivalent. So my first question is: Are they?
And my second question: where is this discrepancy coming from? As mentioned before all my teammates seem to have the same PGSQL version (though there might be a few missing data points). They definitely have the same rails version, so that can't be the source.
The two syntax variants have the same meaning, and PostgreSQL treats them the same. The difference you observe is not caused by a version difference in PostgreSQL, but perhaps in Ruby on Rails.
Related
How can I change the to_tsvector configuration to use a simple tokenization rule like:
lowercase
split by spaces only
Executing the following query:
SELECT to_tsvector('english', 'birthday=19770531 Name=John-Oliver Age=44 Code=AAA-345')
I get these lexemes:
'-345':9 '19770531':2 '44':6 'aaa':8 'age':5 'birthday':1 'code':7 'john':4 'name':3
The kind of searching I'm looking for is like:
(!birthday | birthday=19770531) & (code=AAA-345)
It means, get me all records that has a text "birthday=19770531" or doesn't have "birthday" at all, and a text equals to "code=AAA-345"). The way lexemes are being created it is not possible. I was expecting to have something like this:
'birthday=19770531':1 'age=44':2 'code=aaa-345':4 'name=john-oliver':3
You would have to code a custom parser. This can only be done in C.
But you might be able to use the existing testing parser test_parser, it seems to do what you want. If not, it would at least be a good starting point.
The problem may be that this is in src/test/modules/, and I don't think it ships with most installation packaging. So it might take some effort to get it to install. It would depend on your OS, version, and package manager.
I'm trying to build a list of percentages in grafana, but am having trouble getting divideSeries+wildcards to work right.
I found Grafana dividing 2 series which seemed like what I wanted, but unfortunately there's no mapSeries function in my grafana instance (version 4.6.0-1).
This is what I've got, but instead of specifying the ID "1234", I want to use a wildcard, and have each ID grouped together.
divideSeries(stats.dhcp.pools.1234.cur,stats.dhcp.pools.1234.max)
Logically, I tried: divideSeries(stats.dhcp.pools.*.cur,stats.dhcp.pools.*.max) -- but that does not work. I tried mucking around with asPercent, but it has the same limits as divideSeries does.
I think applyByNode is what I want, but I can't seem to translate the example into something that actually works.
You use graphite as datasource (I think). Functions you mentioned are implemented in graphite-web, you can find docs also for applyByNode
applyByNode(
stats.dhcp.pools.*.*,
3,
'divideSeries(%.cur, %.max)',
'% pct'
)
Note that as of November 2017, applyByNode is not in the default graphite-api install, and requires installation from the github source:
pip install git+git://github.com/brutasse/graphite-api.git
As a side note - you can use any of graphite function, even mapSeries.
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.
We recently switched our definitions from the first to the second format, because OpenLayers threw exceptions on the first one.
The used definitions:
Old:
proj4.defs["EPSG:28992"] = "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs";
New:
proj4.defs("EPSG:28992", "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.040,49.910,465.840,-0.40939,0.35971,-1.86849,4.0772 +units=m +no_defs")
Strange enough, the latter one does correctly transform points. Our points seem to be misaligned, and not by a specific offset, they seem to be just wrong positioned at all. We think this is due to the towgs84 property. Question now is, how is the first format parsed/ handled differently than the secondly? What are the differences? (I am using the same code and newest version of proj4js in both occasions).
I was accidentally loading pro4j twice, once trough potree, and once manually (for openlayers). Turned out one of the two was still on version 2.2.1...
Hi here is my ActiveRelation query that works fine on local development environment (SQLite)
#table2_items = #table1var.table2_items.find(:all, conditions: ["status1 is ? AND status2 is ? AND start_datetime > ?", true, nil, Time.now.to_datetime], order: [:field_id, :created_at])
I think it's just a syntax error... Can anyone help? Thanks
Your SQL ends up with this in it:
status1 is 't'
and that's invalid: is is only used with is null, is distinct from, and similar constructs.
You should upgrade to a more modern syntax and leave most of the work to ActiveRecord:
#table2_items = #table1var.table2_items
.where(:status1 => true, :status2 => nil)
.where('start_datetime > ?', Time.now)
.order(:field_id, :created_at)
That leaves most of the "how do I compare things?" logic up ActiveRecord and is a bit easier to read as the placeholders and their values aren't separated from each other.
Once you have this problem sorted out, you really should install PostgreSQL in your development environment so that you're developing and deploying on the same stack. There are all sorts of differences between databases that no ORM can protect you from.