I want to search for a field that has any values, essentially SQL's IS NOT NULL. I tried
with :fieldA
thinking it means 'with value'. However it does not work. What's the Sunspot way to specify IS NOT NULL?
I found out that I need
without :fieldA, nil
It's kind of obvious once I know it.
Related
I'm making some simple PostgREST queries on a table with network device properties. It seems that eq and not.eq both exclude null values. I've learned that that's a “feature” of PostgreSQL, and can be worked around with the IS DISTINCT FROM operator, which treats null as a comparable value.
I can't find an equivalent (null-safe not-equals) operator in PostgREST. Is there one?
Simplified example:
# https://example.com/api?select=*&name=like.spam-*
[{
"name":"spam-eggs",
"type":"router",
"sector":"cheese"
},{
"name":"spam-ham",
"type":"router",
"sector":null
}]
not.eq.cheese excludes cheese and null:
# https://example.com/api?select=*&name=like.spam-*§or=not.eq.cheese
[]
My awkward workaround is using or to include nulls:
# https://example.com/api?select=*&name=like.spam-*&or=(sector.not.eq.cheese,sector.is.null)
[{
"name":"spam-ham",
"type":"router",
"sector":null
}]
Am I stuck with that workaround, or is there an operator like isdistinctfrom, neq-or-null, etc. that I've missed?
I've checked the code and there's no implementation of IS DISTINCT FROM right now. That is, no PostgREST operator translates to it. The only reference I found is in a comment in this file, but it's for a different issue.
So, yes, right now, your workaround would be the closest you can get to the behavior you want. Creating a FUNCTION with a custom query using IS DISTINCT FROM is another alternative, although it requires more heavy lifting.
What I want is roughly equivalent to
df.where(<condition>).count() != 0
But I'm pretty sure it's not quite smart enough to stop once it finds any such violation. I would expect some sort of aggregator to be able to do this, but I haven't found one? I could do it with a max and some sort of conversion, but again I don't think it would necessarily know to quit (not being specific to bool, I'm not sure if understands no value is larger than true).
More specifically, I want to check if a column contains only a single element. Right now my best idea is to do this is by grabbing the first value and comparing everything.
I would try this option, it should be much faster:
df.where(<condition>).head(1).isEmpty
You can also try to define your conditions on a row together with scala's exists (which stops at the first occurence of true):
df.mapPartitions(rows => if(rows.exists(row => <condition>)) Iterator(1) else Iterator.empty).isEmpty
At the end you should benchmark the alternatives
For example, my input text are:
You can I talk with someone
on entity I have:
#pron:aboutme = I, Me
#pron:aboutother = someone, anyone, everyone, Richard
So... I want get #pron:aboutother literal
The problem is #pron.literal returns "I" and not "someone"
How can get #pron:aboutother input literal for this case?
#sys-number is a shorthand syntax. In this case, you need to use full syntax <?entities['pron'].get(1).literal?> to get the literal of the second detected entity. It might be good to check if there are two entities of the type detected in the input before (otherwise you get arrayoutofbounds exception).
I ran into an odd problem with my slick-query:
As you can see, the function below is compiling although it's basically the same query but with a possitive comparison (I don't know if it's actually doing what it's supposed to do, though). When swapping the order of the if conditions, it tells me that && cannot be resolved. I don't know if that's the case, but I guess the second table query object, in this case contents, doesn't seem to be finished yet. However, that begs the question why the second function/query is compiling properly.
Do you have an answer to this? Am I doing something wrong here?
Thanks in advance!
You should use =!= for inequality and === for equality in queries according to slick docs
I guess I've fixed the problem.
Instead of:
if a.documentId === documentId && b.contentTypeId !== ContentType.PROCESS
I needed to write:
if a.documentId === documentId && !(b.contentTypeId === ContentType.PROCESS)
Still a weird behavior I can't really explain, espacially since negative comparisons like !== are generally allowed in those if-statements
I have a design problem, but don't know how to fix it. I have a Policy object, with a boolean property like so:
public bool IsCancelled
{
get
{
return (CancellationDate != null && Convert.ToDateTime(CancellationDate) < DateTime.Today);
}
}
The problem with this approach is that if I want to get...
context.Policies.where(q => q.IsCancelled)
...LinqToEntities can't execute this against the database; I must load every policy object into memory, like this statement below, which kills performance and is completely unnecessary:
context.policies.ToList().where(q => q.IsCancelled)
A colleague tells me I should be able to use a Func or Expression to do this, but I'm at a loss as to what phrase to even Google for this. Can someone recommend a link or two that explains how to do this?
Keep in mind, I want this to be available to queries like the one above, and to an instance of a Policy object in memory, without having to code the logic twice (DRY and all that).
Thanks.
The problem is your Convert method. I assume CancelationDate is a string. The real problem here is that SQL doesn't do date comparisons as strings, they need to be in date format. This can't be translated to SQL, and thus won't work in the database.
You really should be storing dates as the date type, not as strings. Then it would be trivial. If you can change this, then do it, then no conversion is necessary.
Your other option is to futz with the EntityFunctions, SqlFunctions, DbFunctions to try to make it work.
See:
Comparing date with string Entity Framework