I want to find some data of a application which allows using Apache Lucene syntax for search queries. I search data by date and want to find data from concrete date - concrete day. How can I do that?
Queries:
date: [2010-10-4 TO 2010-10-4]
or
date: 2010-10-4
does not work.
Short answer: there is no "standard" for date query syntax in Lucene. You need to find out the format(s) your app supports.
Long answer: For the last couple years or so, Lucene keeps the numeric data specially encoded. Most likely, the date in the index is kept in the timestamp format. This means the query parser needs to take in the query, chew it and spit out the timestamp. Querying against a raw timestamp is not very practical - at least for humans - and your query parser likely has some pre-defined format it is able to understand.
For example, Solr has a pre-defined set of supported date/time formats and is able to parse those into timestamps.
Don't forget Lucene is just a library and each application (including Solr and the one you are using) is meant to use it the way they like.
I found the solution.
For searching by one conrete day, query:
date: [2010-10-4T00:00:00 TO 2010-10-4T23:59:59]
is correct
I put the date range without the hyphens and It worked for me.
date: [20210901 TO 20211101 ]
See the doc Range Searches
Related
I have a PostgreSQL table which has a column of the type interval which is storing a time duration in the ISO 8601 format i.e. P1D equals "1 day".
The problem I am having is that when selecting this data from the database using Knex.js the data is converted from the string P1D into a JSON object {"days":1}, if I execute the same basic select query in the command line interface I get the string P1D back, and have the option to set the style of output SET intervalStyle = iso_8601.
As best I can tell this is being doing by a dependency of Knex.js called "node-pg-types" which in turn uses "postgres-interval". In Bookshelf.js you can set a data processor, and in using the "pg" module directly you can set different type behaviours, however it's not clear at all how to modify the behaviour of Knex.js in this regard, and yet Bookshelf.js can do this and is built on Knex.js.
In short my question is how do I make Knex.js output ISO 8601 style intervals on interval columns rather than a JSON object?
It turns out that through my research jumping from one module to another, that indeed Knex.js does use "node-pg-types" to format the interval columns, and that in turn is using "postgres-interval", neither module document this well at all.
In looking into "postgres-interval" it was evident that the data returned was a JavaScript object which was being encoded into what looked like JSON, however reading the documentation on this module it actually has functions you can call to get the data in any format:
https://github.com/bendrucker/postgres-interval
interval.toPostgres() -> string
Returns an interval string. This allows the interval object to be passed into prepared statements.
interval.toISO() -> string
Returns an ISO 8601 compliant string.
So the answer is to append .toISO() to your code.
I will notify the developer that this particular behaviour is not well documented so they can look to improve awareness of how Knex.js passes off some of the work to other modules which also pass work off, however I wrote this self answered question so no one else has to spend countless hours trying to figure this out.
I am building a lucene query for an indexed object to determine if current time lies between the range of start Time and end Time. I'm unable to get the exact lucene query .
org.apache.lucene.search.Query luceneQuery5=queryBuilder3.bool()
.must(queryBuilder3.keyword().onFields("TimeDependentProfileKey").matching("TimeKey").createQuery())
.must(queryBuilder3.range().onField("StartTime").above(new Time(0)).createQuery())
.must(queryBuilder3.range().onField("StopTime").below(new Time(0)).createQuery()).createQuery();`
The lucene query which was generated looks like:
+TimeDependentProfileKey:3 +StartTime:[19700101000000000 TO *] +StopTime:[* TO 19700101000000000]
how do i change the format of timestamp, can anyone please help me.
By searching for a date object, you are deferring formatting to hibernate. I would consider the format you specified as functional, though perhaps not ideal. If you want to use your own formatting, you must deal in strings, be consistent in your formatting, and make sure your format will work well for sorting and range queries as a string.
If you want to have hibernate handle formatting dates for you, you need to define your date field with a #DateBridge(resolution = ...) annotation. This ensures that hibernate will format dates effective for correct range querying and sorting in lucene, and allows you to query against the field with date objects instead of strings.
Here is my problem. the date that i got from my database contains "12/31/2013". Based on this date, the format is mm/dd/yy. Now the question is how do i makes it that no matter what format of the date in the user's computer, they will always read the date "12/31/2013" as mm/dd/yy instead of example dd/mm/yy which when it reads it contains an error due to there is no 31 month. i try the split method on the date i receive from my database but i coudn't get it to confirm to the format that is independent from the user's computer
Is your date being stored in your database as an actual date format, or as a string?
Remember that DateTime.Parse by default, uses the current user's current system date/time formatting settings (so UK users are dd/MM/yyyy, but US users are MM/dd/yyyy). If you want uniform parsing then use DateTime.ParseExact and specify an exact parsing format string.
One rule of thumb that's useful to remember is that "if you're ever using String.Split, you're probably doing something wrong" (I'll make exceptions for quick-and-dirty by-design programs, but for parsing a Format-string, Regular-expression, or Finite state machine is more performant (less string allocations) and less brittle.
Back on-topic, if your database is storing objects as a date or datetime then don't use strings at all. Use the .GetDateString(int) method of IDataReader or typed field properties of EF classes.
How did you get a date from your database? Did you store the date as a string? If at all possible, consider keeping the date as a DateTime variable rather than a string. If not possible, look into the DateTime.TryParse method which supports internationalization and should be able to understand with the user's UI localization settings.
Its not clear if you want to read the same format from the database or display it on the screen (UI)
If its from the sql server, consider using convert <- follow this link
I put some fields like manufacturer, group, description, num.
SimpleFaceted works ok if I use query like sometext* with QueryParser.
Im trying to use num:[100 TO 200],
num is NumericField with SetIntValue(150).
I got nothing returned.
Am I missing something?
You can't use a normal query parser for numeric range queries. However, assuming you know at query time which fields are numeric, it isn't too hard to derive a class from the Lucene query parser and create numeric range queries as necessary.
Support for numeric queries in the standard query parser looks like it should be available in Lucene.Net when a port of v3.4 is available. (See Java Lucene issue 1768)
Good luck,
Is there a way to change the default format of a date in Postgres?
Normally when I query a Postgres database, dates come out as yyyy-mm-dd hh:mm:ss+tz, like 2011-02-21 11:30:00-05.
But one particular program the dates come out yyyy-mm-dd hh:mm:ss.s, that is, there is no time zone and it shows tenths of a second.
Apparently something is changing the default date format, but I don't know what or where. I don't think it's a server-side configuration parameter, because I can access the same database with a different program and I get the format with the timezone.
I care because it appears to be ignoring my "set timezone" calls in addition to changing the format. All times come out EST.
Additional info:
If I write "select somedate from sometable" I get the "no timezone" format. But if I write "select to_char(somedate::timestamptz, 'yyyy-mm-dd hh24:mi:ss-tz')" then timezones work as I would expect.
This really sounds to me like something is setting all timestamps to implicitly be "to_char(date::timestamp, 'yyyy-mm-dd hh24:mi:ss.m')". But I can't find anything in the documentation about how I would do this if I wanted to, nor can I find anything in the code that appears to do this. Though as I don't know what to look for, that doesn't prove much.
Never mind :'(
I found my problem. I was thinking that I was looking directly at the string coming back from the database. But I was overlooking that it was reading it as a Timestamp and then converting the Timestamp to a string. This was buried inside a function called "getString", which is what threw me off. I was thinking it was ResultSet.getString, but it was really our own function with the same name. Oops. What idiot wrote that function?! Oh, it was me ...
Thanks to all who tried to help. I'll give you each an upvote for your trouble.
I believe the table columns are specified differently. Try these variants:
timestamp
timestamp(0) no millis
timestamptz with timezone
timestamptz(0) with timezone, no millis
With which client are you running the select statements? Formatting the output is the application's responsibility, so without knowing which application you use to display the data, it's hard to tell.
Assuming you are using psql, you can change the date format using the SET command:
http://www.postgresql.org/docs/current/static/sql-set.html
Which is essentially a way to change the configuration parameters. The ones that are responsible for formatting data are documented here:
http://www.postgresql.org/docs/current/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
Daniel tells me to post my findings as an answer and accept it to close the question. Okay.
I found that the date format I was seeing that did not include a time zone was not what was coming directly from Postgres, but that there were a couple of function calls that I was missing that converted the incoming date to a java.util.Timestamp, and then from the java.util.Timestamp to a String. It was in this conversion from the Timestamp to the String that the time zone was defaulting to EST.
In my own humble defense, my mistake was not as dumb as it may sound. :-0 We had the execution of the query in a subclass that read the results into a List, which we do to allow modification of the query results before output. (In this case we are adding a coule of columns that are derived from the stored columns.) Then we have a set of functions that resemble the JDBC functions to pull the data out of the List, so a calling program can easily switch from processing a query directly to processing the List. When I was wrestling with the date format problem, it just didn't register on me that I wasn't looking at "real JDBC", but at "simulated JDBC" calls.