search

blevesearch / bleve

A modern text/numeric/geo-spatial/vector indexing library for go
Apache License 2.0
9.97k stars 676 forks source link

there's no way to customize datefield format #434

Open darren opened 7 years ago

darren commented 7 years ago

We can customized datetime parser using registry.RegisterDateTimeParser but there's no RegisterDateTimeFormat. The datefield is hardcoded using time.RFC3339 now.

mschoch commented 7 years ago

Can you explain which behavior you want to change? We support indexing and searching dates using other formats through the DateTimeParser functionality. The only thing that I know of that is hard-coded is that when you choose to "load a stored field" that contains a date, that is returned to you as time.RFC3339. Is this the behavior you want to make configurable?

darren commented 7 years ago

@mschoch yes, make the returned time field format configurable.

mschoch commented 7 years ago

I'm not really sure this going to happen. Our whole support for stored fields is poorly implemented, and the only way for us to address this is to introduce a whole new mechanism for date time formatters. This takes us further and further away from what we should be doing as a good Go library.

I'd much prefer a solution in which we use something like 'gob' to store all fields, and we simply return it back to you like it came in. If it came in as a string, you get back the exact string. If it came in as a time.Time, then you get that back. For stored fields we shouldn't really care about the representation, we should just give you back what you gave us.

masterada commented 3 years ago

+1 can you at least change it to RFC3339Nano please?

as far as i can see the sub-seconds are properly stored, but then they can't be read back

mschoch commented 3 years ago

I guess we can consider this again for v3, but I consider it risky to change before the next major version because applications may depend on the format of the string to parse it.

If you really need to access the sub-seconds, you can call the Document() method yourself and get access to the time.Time directly. The only downside of this approach is that it will not be in the same index snapshot as the search, so there is the possibility it has been updated or deleted since the search executed.

masterada commented 3 years ago

I ended up creating 2 fields, one with datetime type indexed and not stored, the other with string type stored but not indexed. I use the datetime type for search, and the string type for retrieving the field.