On Tue, May 29, 2012 at 6:38 PM, Michael McCandless <[email protected]> wrote: > On Tue, May 29, 2012 at 12:31 PM, Robert Muir <[email protected]> wrote: >> On Tue, May 29, 2012 at 12:20 PM, Michael McCandless >> <[email protected]> wrote: >>> I agree this inconsistency is bad... and silently losing stuff (float >>> 2.5 becomes int 2) is really bad. We should do something before 4.0. >>> >>> I would prefer idea 2, i.e. that we never allow changing/promoting a DV >>> type for a given field, and that we do our best to throw clear exc if you >>> do so. I realize this is different from other things in Lucene where >>> "anything >>> goes" but DV is new in 4.0 so we are free to set new rules.
+1 I think we can easily build a "global" view of DV types like we do for field numbers and be consistent across DWPT >>> >>> Also, if this somehow later proves to be a bad decision, we can always >>> add back in this leniency ... but not vice-versa. >> >> Right, this would certainly simplify things: but as I mentioned its a >> little cruel if someone is using a 16-bit type (for DV or norms) and >> decides they are running out of space and need 32-bits or something. >> >> Maybe i'm worrying about it too much? > > I think we can wait and see how many users complain about it ... I > suspect users that change up the bit width of their norms are rather > advanced and can handle re-indexing. > >> One idea would be to move this type promotion to a >> FilterIndexReader+AddIndexes tool in contrib, e.g. a general tool that >> can upwards cast a norm or dv type? >> >> Ive thought about this before: maybe having a nice tool to change >> these types of things, e.g. completely remove a field, or unomit norms >> (but you must specify default value), or other crazy things like that? > > I like that idea! This way there's an "out" for such users... +1 as well simon > > Mike McCandless > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
