Is it possible to disable dynamic index creation and throw an exception if a dynamic index must be created to fulfill a query? Is there some way to accomplish this with the configuration settings here: http://ravendb.net/docs/server/administration/configuration ?
On Monday, 9 July 2012, Ken Dale wrote:
> Is it possible to disable dynamic index creation and throw an exception if
> a dynamic index must be created to fulfill a query? Is there some way to
> accomplish this with the configuration settings here:
> http://ravendb.net/docs/server/administration/configuration ?
On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
> Is it possible to disable dynamic index creation and throw an exception if
> a dynamic index must be created to fulfill a query? Is there some way to
> accomplish this with the configuration settings here:
> http://ravendb.net/docs/server/administration/configuration ?
On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
> Currently,no. > Can you explain why you want to do this?
> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
>> Is it possible to disable dynamic index creation and throw an exception >> if a dynamic index must be created to fulfill a query? Is there some way to >> accomplish this with the configuration settings here: >> http://ravendb.net/docs/server/administration/configuration ?
Can you create an issue for this?
It is a more complex feature than you think, it requires us to have hooks
into query optimizer so that we can report errors.
On Tue, Jul 10, 2012 at 4:09 PM, Chris Marisic <ch...@marisic.com> wrote:
> Total control over indexes, i never want an index randomly created in
> production. I'd rather it fail, than compile a whole index.
> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>> Currently,no.
>> Can you explain why you want to do this?
>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
On Tuesday, July 10, 2012 9:24:00 AM UTC-4, Oren Eini wrote:
> Can you create an issue for this? > It is a more complex feature than you think, it requires us to have hooks > into query optimizer so that we can report errors.
> On Tue, Jul 10, 2012 at 4:09 PM, Chris Marisic <ch...@marisic.com> wrote:
>> Total control over indexes, i never want an index randomly created in >> production. I'd rather it fail, than compile a whole index.
>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>> Currently,no. >>> Can you explain why you want to do this?
>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
Wouldn't/shouldn't this be caught in QA? Run through all automated and
manual tests. Dynamic index count should be zero.
If I didn't catch in QA, i'd rather get a warning, if anything, rather than
blow up production. My wager would be that- if it was missed by QA, the
dynamic index would be in something with lower impact which wouldn't cause
too many problems.
On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
> Wouldn't/shouldn't this be caught in QA? Run through all automated and
> manual tests. Dynamic index count should be zero.
> If I didn't catch in QA, i'd rather get a warning, if anything, rather
> than blow up production. My wager would be that- if it was missed by QA,
> the dynamic index would be in something with lower impact which wouldn't
> cause too many problems.
> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>> Total control over indexes, i never want an index randomly created in
>> production. I'd rather it fail, than compile a whole index.
>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>> Currently,no.
>>> Can you explain why you want to do this?
>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
Perhaps. But turning on a flag that means, "shut down production if this
happens anywhere in the app" would give me more than a little pause. Lol.
On Jul 10, 2012 8:49 AM, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Kijana,
> There are scenarios where you want to fail rather than create a new index.
> I can't think of one off hand, but I am sure there are :-)
> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <kijana.wood...@gmail.com>wrote:
>> Wouldn't/shouldn't this be caught in QA? Run through all automated and
>> manual tests. Dynamic index count should be zero.
>> If I didn't catch in QA, i'd rather get a warning, if anything, rather
>> than blow up production. My wager would be that- if it was missed by QA,
>> the dynamic index would be in something with lower impact which wouldn't
>> cause too many problems.
>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>> Total control over indexes, i never want an index randomly created in
>>> production. I'd rather it fail, than compile a whole index.
>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>> Currently,no.
>>>> Can you explain why you want to do this?
>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
Hmmm. I suppose it would just affect the particular query/business function
without the index, but that's a pretty nasty way to find out your QA
process has holes. And you'd better have a pretty fast launch process to
get the fix out there. Angry execs. Haha.
On Jul 10, 2012 8:53 AM, "Kijana Woodard" <kijana.wood...@gmail.com> wrote:
> Perhaps. But turning on a flag that means, "shut down production if this
> happens anywhere in the app" would give me more than a little pause. Lol.
> On Jul 10, 2012 8:49 AM, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
> wrote:
>> Kijana,
>> There are scenarios where you want to fail rather than create a new index.
>> I can't think of one off hand, but I am sure there are :-)
>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <kijana.wood...@gmail.com
>> > wrote:
>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and
>>> manual tests. Dynamic index count should be zero.
>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather
>>> than blow up production. My wager would be that- if it was missed by QA,
>>> the dynamic index would be in something with lower impact which wouldn't
>>> cause too many problems.
>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>> Total control over indexes, i never want an index randomly created in
>>>> production. I'd rather it fail, than compile a whole index.
>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>> Currently,no.
>>>>> Can you explain why you want to do this?
>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
aye...@ayende.com> wrote:
> Kijana,
> There are scenarios where you want to fail rather than create a new index.
> I can't think of one off hand, but I am sure there are :-)
> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <kijana.wood...@gmail.com>wrote:
>> Wouldn't/shouldn't this be caught in QA? Run through all automated and
>> manual tests. Dynamic index count should be zero.
>> If I didn't catch in QA, i'd rather get a warning, if anything, rather
>> than blow up production. My wager would be that- if it was missed by QA,
>> the dynamic index would be in something with lower impact which wouldn't
>> cause too many problems.
>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>> Total control over indexes, i never want an index randomly created in
>>> production. I'd rather it fail, than compile a whole index.
>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>> Currently,no.
>>>> Can you explain why you want to do this?
>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
Unfortunately this statement does not seem to be sufficient Itamar. We analyzed our code base and do not have a single usage of a query call for a non-specified index. We have temp indexes that are created even when static ones include all of the fields that the temp indexes are created for. We have been able to produce this 100% consistently in our code base for indexes that have transform results, however we have not been able to reproduce this occurrence outside of our solution to submit a failing test. So far the only thing we've been able to come up with is to set Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't disappear.
On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
> In those cases, I'd suggest going the route Matt suggested - make queries > to named indexes, never rely on the query optimizer
> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
>> Kijana, >> There are scenarios where you want to fail rather than create a new index. >> I can't think of one off hand, but I am sure there are :-)
>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <kijana.wood...@gmail.com >> > wrote:
>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and >>> manual tests. Dynamic index count should be zero.
>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather >>> than blow up production. My wager would be that- if it was missed by QA, >>> the dynamic index would be in something with lower impact which wouldn't >>> cause too many problems. >>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>> Total control over indexes, i never want an index randomly created in >>>> production. I'd rather it fail, than compile a whole index.
>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>> Currently,no. >>>>> Can you explain why you want to do this?
>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
On Tuesday, 10 July 2012 17:17:11 UTC+1, Chris Marisic wrote:
> Unfortunately this statement does not seem to be sufficient Itamar. We > analyzed our code base and do not have a single usage of a query call for a > non-specified index. We have temp indexes that are created even when static > ones include all of the fields that the temp indexes are created for. We > have been able to produce this 100% consistently in our code base for > indexes that have transform results, however we have not been able to > reproduce this occurrence outside of our solution to submit a failing test. > So far the only thing we've been able to come up with is to set > Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't > disappear.
> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>> In those cases, I'd suggest going the route Matt suggested - make queries >> to named indexes, never rely on the query optimizer
>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> wrote:
>>> Kijana, >>> There are scenarios where you want to fail rather than create a new >>> index. >>> I can't think of one off hand, but I am sure there are :-)
>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>> kijana.wood...@gmail.com> wrote:
>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and >>>> manual tests. Dynamic index count should be zero.
>>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather >>>> than blow up production. My wager would be that- if it was missed by QA, >>>> the dynamic index would be in something with lower impact which wouldn't >>>> cause too many problems. >>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>> Total control over indexes, i never want an index randomly created in >>>>> production. I'd rather it fail, than compile a whole index.
>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>> Currently,no. >>>>>> Can you explain why you want to do this?
>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com> wrote:
> Unfortunately this statement does not seem to be sufficient Itamar. We
> analyzed our code base and do not have a single usage of a query call for a
> non-specified index. We have temp indexes that are created even when static
> ones include all of the fields that the temp indexes are created for. We
> have been able to produce this 100% consistently in our code base for
> indexes that have transform results, however we have not been able to
> reproduce this occurrence outside of our solution to submit a failing test.
> So far the only thing we've been able to come up with is to set
> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't
> disappear.
> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>> In those cases, I'd suggest going the route Matt suggested - make queries
>> to named indexes, never rely on the query optimizer
>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) <
>> aye...@ayende.com> wrote:
>>> Kijana,
>>> There are scenarios where you want to fail rather than create a new
>>> index.
>>> I can't think of one off hand, but I am sure there are :-)
>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <
>>> kijana.wood...@gmail.com> wrote:
>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and
>>>> manual tests. Dynamic index count should be zero.
>>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather
>>>> than blow up production. My wager would be that- if it was missed by QA,
>>>> the dynamic index would be in something with lower impact which wouldn't
>>>> cause too many problems.
>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>> Total control over indexes, i never want an index randomly created in
>>>>> production. I'd rather it fail, than compile a whole index.
>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>> Currently,no.
>>>>>> Can you explain why you want to do this?
>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
No range queries, stable 960, the indexes it creates are dead simple:
from doc in docs.Things select new { Created = doc.Created }
Field: Created Storage: No Indexing Default Sort String
In all of our static indexes Created is in the map statement (Created is a DateTime) however it doesn't display in the fields list. We also tried numerous combinations of Store/Index/Sorting settings and it would happen regardless, however once we took away the TransformResults it would work as expected, but that isn't really an option as it's needed.
On Tuesday, July 10, 2012 12:31:15 PM UTC-4, Itamar Syn-Hershko wrote:
> Does this involve range queries? we had a bug that could have caused this > that we fixed
> What build are you using?
> On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com> wrote:
>> Unfortunately this statement does not seem to be sufficient Itamar. We >> analyzed our code base and do not have a single usage of a query call for a >> non-specified index. We have temp indexes that are created even when static >> ones include all of the fields that the temp indexes are created for. We >> have been able to produce this 100% consistently in our code base for >> indexes that have transform results, however we have not been able to >> reproduce this occurrence outside of our solution to submit a failing test. >> So far the only thing we've been able to come up with is to set >> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't >> disappear.
>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>> In those cases, I'd suggest going the route Matt suggested - make >>> queries to named indexes, never rely on the query optimizer
>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> wrote:
>>>> Kijana, >>>> There are scenarios where you want to fail rather than create a new >>>> index. >>>> I can't think of one off hand, but I am sure there are :-)
>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>> kijana.wood...@gmail.com> wrote:
>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and >>>>> manual tests. Dynamic index count should be zero.
>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather >>>>> than blow up production. My wager would be that- if it was missed by QA, >>>>> the dynamic index would be in something with lower impact which wouldn't >>>>> cause too many problems. >>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>> Total control over indexes, i never want an index randomly created in >>>>>> production. I'd rather it fail, than compile a whole index.
>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>> Currently,no. >>>>>>> Can you explain why you want to do this?
>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
There was a bug/issue raised a while ago where indexes were rebuit when all that had changed was the TransformResults (whereas it didn't need to be rebuilt).
On Tuesday, 10 July 2012 17:40:45 UTC+1, Chris Marisic wrote:
> No range queries, stable 960, the indexes it creates are dead simple:
> from doc in docs.Things > select new { Created = doc.Created }
> Field: Created Storage: No Indexing Default Sort String
> In all of our static indexes Created is in the map statement (Created is a > DateTime) however it doesn't display in the fields list. We also tried > numerous combinations of Store/Index/Sorting settings and it would happen > regardless, however once we took away the TransformResults it would work as > expected, but that isn't really an option as it's needed.
> On Tuesday, July 10, 2012 12:31:15 PM UTC-4, Itamar Syn-Hershko wrote:
>> Does this involve range queries? we had a bug that could have caused this >> that we fixed
>> What build are you using?
>> On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> Unfortunately this statement does not seem to be sufficient Itamar. We >>> analyzed our code base and do not have a single usage of a query call for a >>> non-specified index. We have temp indexes that are created even when static >>> ones include all of the fields that the temp indexes are created for. We >>> have been able to produce this 100% consistently in our code base for >>> indexes that have transform results, however we have not been able to >>> reproduce this occurrence outside of our solution to submit a failing test. >>> So far the only thing we've been able to come up with is to set >>> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't >>> disappear.
>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>> In those cases, I'd suggest going the route Matt suggested - make >>>> queries to named indexes, never rely on the query optimizer
>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>>> aye...@ayende.com> wrote:
>>>>> Kijana, >>>>> There are scenarios where you want to fail rather than create a new >>>>> index. >>>>> I can't think of one off hand, but I am sure there are :-)
>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>>> kijana.wood...@gmail.com> wrote:
>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated >>>>>> and manual tests. Dynamic index count should be zero.
>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, >>>>>> rather than blow up production. My wager would be that- if it was missed by >>>>>> QA, the dynamic index would be in something with lower impact which >>>>>> wouldn't cause too many problems. >>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>>> Total control over indexes, i never want an index randomly created >>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>> Currently,no. >>>>>>>> Can you explain why you want to do this?
>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
When tracing this through server logging we see it specifically queries the named index, then immediately says "creating new temp index" and then says querying the temp index.
On Tuesday, July 10, 2012 12:22:46 PM UTC-4, Matt Warren wrote:
> That sound like a bug, my understanding was that the query optimiser is > only used if you *don't* explicitly specify an index.
> On Tuesday, 10 July 2012 17:17:11 UTC+1, Chris Marisic wrote:
>> Unfortunately this statement does not seem to be sufficient Itamar. We >> analyzed our code base and do not have a single usage of a query call for a >> non-specified index. We have temp indexes that are created even when static >> ones include all of the fields that the temp indexes are created for. We >> have been able to produce this 100% consistently in our code base for >> indexes that have transform results, however we have not been able to >> reproduce this occurrence outside of our solution to submit a failing test. >> So far the only thing we've been able to come up with is to set >> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't >> disappear.
>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>> In those cases, I'd suggest going the route Matt suggested - make >>> queries to named indexes, never rely on the query optimizer
>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> wrote:
>>>> Kijana, >>>> There are scenarios where you want to fail rather than create a new >>>> index. >>>> I can't think of one off hand, but I am sure there are :-)
>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>> kijana.wood...@gmail.com> wrote:
>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated and >>>>> manual tests. Dynamic index count should be zero.
>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, rather >>>>> than blow up production. My wager would be that- if it was missed by QA, >>>>> the dynamic index would be in something with lower impact which wouldn't >>>>> cause too many problems. >>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>> Total control over indexes, i never want an index randomly created in >>>>>> production. I'd rather it fail, than compile a whole index.
>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>> Currently,no. >>>>>>> Can you explain why you want to do this?
>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com> wrote:
On Tuesday, 10 July 2012 18:07:42 UTC+1, Chris Marisic wrote:
> When tracing this through server logging we see it specifically queries > the named index, then immediately says "creating new temp index" and then > says querying the temp index.
> On Tuesday, July 10, 2012 12:22:46 PM UTC-4, Matt Warren wrote:
>> That sound like a bug, my understanding was that the query optimiser is >> only used if you *don't* explicitly specify an index.
>> On Tuesday, 10 July 2012 17:17:11 UTC+1, Chris Marisic wrote:
>>> Unfortunately this statement does not seem to be sufficient Itamar. We >>> analyzed our code base and do not have a single usage of a query call for a >>> non-specified index. We have temp indexes that are created even when static >>> ones include all of the fields that the temp indexes are created for. We >>> have been able to produce this 100% consistently in our code base for >>> indexes that have transform results, however we have not been able to >>> reproduce this occurrence outside of our solution to submit a failing test. >>> So far the only thing we've been able to come up with is to set >>> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't >>> disappear.
>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>> In those cases, I'd suggest going the route Matt suggested - make >>>> queries to named indexes, never rely on the query optimizer
>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>>> aye...@ayende.com> wrote:
>>>>> Kijana, >>>>> There are scenarios where you want to fail rather than create a new >>>>> index. >>>>> I can't think of one off hand, but I am sure there are :-)
>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>>> kijana.wood...@gmail.com> wrote:
>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated >>>>>> and manual tests. Dynamic index count should be zero.
>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, >>>>>> rather than blow up production. My wager would be that- if it was missed by >>>>>> QA, the dynamic index would be in something with lower impact which >>>>>> wouldn't cause too many problems. >>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>>> Total control over indexes, i never want an index randomly created >>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>> Currently,no. >>>>>>>> Can you explain why you want to do this?
>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
> If should use an existing index unless your indexes happen to start with > "dynamic/"?
> On Tuesday, 10 July 2012 18:07:42 UTC+1, Chris Marisic wrote:
>> When tracing this through server logging we see it specifically queries >> the named index, then immediately says "creating new temp index" and then >> says querying the temp index.
>> On Tuesday, July 10, 2012 12:22:46 PM UTC-4, Matt Warren wrote:
>>> That sound like a bug, my understanding was that the query optimiser is >>> only used if you *don't* explicitly specify an index.
>>> On Tuesday, 10 July 2012 17:17:11 UTC+1, Chris Marisic wrote:
>>>> Unfortunately this statement does not seem to be sufficient Itamar. We >>>> analyzed our code base and do not have a single usage of a query call for a >>>> non-specified index. We have temp indexes that are created even when static >>>> ones include all of the fields that the temp indexes are created for. We >>>> have been able to produce this 100% consistently in our code base for >>>> indexes that have transform results, however we have not been able to >>>> reproduce this occurrence outside of our solution to submit a failing test. >>>> So far the only thing we've been able to come up with is to set >>>> Raven/TempIndexPromotionMinimumQueryCount to 1 so atleast the indexes don't >>>> disappear.
>>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>>> In those cases, I'd suggest going the route Matt suggested - make >>>>> queries to named indexes, never rely on the query optimizer
>>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>>>> aye...@ayende.com> wrote:
>>>>>> Kijana, >>>>>> There are scenarios where you want to fail rather than create a new >>>>>> index. >>>>>> I can't think of one off hand, but I am sure there are :-)
>>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>>>> kijana.wood...@gmail.com> wrote:
>>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated >>>>>>> and manual tests. Dynamic index count should be zero.
>>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, >>>>>>> rather than blow up production. My wager would be that- if it was missed by >>>>>>> QA, the dynamic index would be in something with lower impact which >>>>>>> wouldn't cause too many problems. >>>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>>>> Total control over indexes, i never want an index randomly created >>>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>>> Currently,no. >>>>>>>>> Can you explain why you want to do this?
>>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
Chris,
TransformResults tells RavenDB to avoid using this index, because the
output is different than what the user may expect.
Thinking about this, we can probably use this anyway, just skip the
transform results.
On Tue, Jul 10, 2012 at 7:40 PM, Chris Marisic <ch...@marisic.com> wrote:
> No range queries, stable 960, the indexes it creates are dead simple:
> from doc in docs.Things
> select new { Created = doc.Created }
> Field: Created Storage: No Indexing Default Sort String
> In all of our static indexes Created is in the map statement (Created is a
> DateTime) however it doesn't display in the fields list. We also tried
> numerous combinations of Store/Index/Sorting settings and it would happen
> regardless, however once we took away the TransformResults it would work as
> expected, but that isn't really an option as it's needed.
> On Tuesday, July 10, 2012 12:31:15 PM UTC-4, Itamar Syn-Hershko wrote:
>> Does this involve range queries? we had a bug that could have caused this
>> that we fixed
>> What build are you using?
>> On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> Unfortunately this statement does not seem to be sufficient Itamar. We
>>> analyzed our code base and do not have a single usage of a query call for a
>>> non-specified index. We have temp indexes that are created even when static
>>> ones include all of the fields that the temp indexes are created for. We
>>> have been able to produce this 100% consistently in our code base for
>>> indexes that have transform results, however we have not been able to
>>> reproduce this occurrence outside of our solution to submit a failing test.
>>> So far the only thing we've been able to come up with is to set Raven/**
>>> TempIndexPromotionMinimumQuery**Count to 1 so atleast the indexes don't
>>> disappear.
>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>> In those cases, I'd suggest going the route Matt suggested - make
>>>> queries to named indexes, never rely on the query optimizer
>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) <
>>>> aye...@ayende.com> wrote:
>>>>> Kijana,
>>>>> There are scenarios where you want to fail rather than create a new
>>>>> index.
>>>>> I can't think of one off hand, but I am sure there are :-)
>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <
>>>>> kijana.wood...@gmail.com> wrote:
>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated
>>>>>> and manual tests. Dynamic index count should be zero.
>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything,
>>>>>> rather than blow up production. My wager would be that- if it was missed by
>>>>>> QA, the dynamic index would be in something with lower impact which
>>>>>> wouldn't cause too many problems.
>>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>>> Total control over indexes, i never want an index randomly created
>>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>> Currently,no.
>>>>>>>> Can you explain why you want to do this?
>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
On Tuesday, July 10, 2012 1:57:28 PM UTC-4, Oren Eini wrote:
> Chris, > TransformResults tells RavenDB to avoid using this index, because the > output is different than what the user may expect. > Thinking about this, we can probably use this anyway, just skip the > transform results.
> On Tue, Jul 10, 2012 at 7:40 PM, Chris Marisic <ch...@marisic.com> wrote:
>> No range queries, stable 960, the indexes it creates are dead simple:
>> from doc in docs.Things >> select new { Created = doc.Created }
>> Field: Created Storage: No Indexing Default Sort String
>> In all of our static indexes Created is in the map statement (Created is >> a DateTime) however it doesn't display in the fields list. We also tried >> numerous combinations of Store/Index/Sorting settings and it would happen >> regardless, however once we took away the TransformResults it would work as >> expected, but that isn't really an option as it's needed.
>> On Tuesday, July 10, 2012 12:31:15 PM UTC-4, Itamar Syn-Hershko wrote:
>>> Does this involve range queries? we had a bug that could have caused >>> this that we fixed
>>> What build are you using?
>>> On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>> Unfortunately this statement does not seem to be sufficient Itamar. We >>>> analyzed our code base and do not have a single usage of a query call for a >>>> non-specified index. We have temp indexes that are created even when static >>>> ones include all of the fields that the temp indexes are created for. We >>>> have been able to produce this 100% consistently in our code base for >>>> indexes that have transform results, however we have not been able to >>>> reproduce this occurrence outside of our solution to submit a failing test. >>>> So far the only thing we've been able to come up with is to set Raven/* >>>> *TempIndexPromotionMinimumQuery**Count to 1 so atleast the indexes >>>> don't disappear.
>>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>>> In those cases, I'd suggest going the route Matt suggested - make >>>>> queries to named indexes, never rely on the query optimizer
>>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) < >>>>> aye...@ayende.com> wrote:
>>>>>> Kijana, >>>>>> There are scenarios where you want to fail rather than create a new >>>>>> index. >>>>>> I can't think of one off hand, but I am sure there are :-)
>>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard < >>>>>> kijana.wood...@gmail.com> wrote:
>>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated >>>>>>> and manual tests. Dynamic index count should be zero.
>>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything, >>>>>>> rather than blow up production. My wager would be that- if it was missed by >>>>>>> QA, the dynamic index would be in something with lower impact which >>>>>>> wouldn't cause too many problems. >>>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com> wrote:
>>>>>>>> Total control over indexes, i never want an index randomly created >>>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>>> Currently,no. >>>>>>>>> Can you explain why you want to do this?
>>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
* Transform Results no longer prevent an index from being selected as the
target of a dynamic query
* You can now ask RavenDB why it selected a particular index:
localhost:8080/indexes/dynamic/Companies?query=Name:Northwind*&explain=true *
** *We have a new config option:
Raven/CreateTemporaryIndexesForAdHocQueriesIfNeeded
On Tue, Jul 10, 2012 at 9:22 PM, Chris Marisic <ch...@marisic.com> wrote:
> I'm confused by this statement. We're using the TransformResults for the
> most standard reason so instead of showing:
> Book | Author
> Harry Potter | authors/1
> Twilight | authors/2
> That we can show a list that uses names not ids.
> Book | Author
> Harry Potter | Witch lady
> Twilight | World's worst author
> We are reading from the results of the index with the query using As<>
> because we only want the values from the index not full documents.
> On Tuesday, July 10, 2012 1:57:28 PM UTC-4, Oren Eini wrote:
>> Chris,
>> TransformResults tells RavenDB to avoid using this index, because the
>> output is different than what the user may expect.
>> Thinking about this, we can probably use this anyway, just skip the
>> transform results.
>> On Tue, Jul 10, 2012 at 7:40 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> No range queries, stable 960, the indexes it creates are dead simple:
>>> from doc in docs.Things
>>> select new { Created = doc.Created }
>>> Field: Created Storage: No Indexing Default Sort String
>>> In all of our static indexes Created is in the map statement (Created is
>>> a DateTime) however it doesn't display in the fields list. We also tried
>>> numerous combinations of Store/Index/Sorting settings and it would happen
>>> regardless, however once we took away the TransformResults it would work as
>>> expected, but that isn't really an option as it's needed.
>>> On Tuesday, July 10, 2012 12:31:15 PM UTC-4, Itamar Syn-Hershko wrote:
>>>> Does this involve range queries? we had a bug that could have caused
>>>> this that we fixed
>>>> What build are you using?
>>>> On Tue, Jul 10, 2012 at 7:17 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>> Unfortunately this statement does not seem to be sufficient Itamar. We
>>>>> analyzed our code base and do not have a single usage of a query call for a
>>>>> non-specified index. We have temp indexes that are created even when static
>>>>> ones include all of the fields that the temp indexes are created for. We
>>>>> have been able to produce this 100% consistently in our code base for
>>>>> indexes that have transform results, however we have not been able to
>>>>> reproduce this occurrence outside of our solution to submit a failing test.
>>>>> So far the only thing we've been able to come up with is to set Raven/
>>>>> **TempIndexPromotionMinimu**mQuery**Count to 1 so atleast the indexes
>>>>> don't disappear.
>>>>> On Tuesday, July 10, 2012 10:18:33 AM UTC-4, Itamar Syn-Hershko wrote:
>>>>>> In those cases, I'd suggest going the route Matt suggested - make
>>>>>> queries to named indexes, never rely on the query optimizer
>>>>>> On Tue, Jul 10, 2012 at 4:49 PM, Oren Eini (Ayende Rahien) <
>>>>>> aye...@ayende.com> wrote:
>>>>>>> Kijana,
>>>>>>> There are scenarios where you want to fail rather than create a new
>>>>>>> index.
>>>>>>> I can't think of one off hand, but I am sure there are :-)
>>>>>>> On Tue, Jul 10, 2012 at 4:41 PM, Kijana Woodard <
>>>>>>> kijana.wood...@gmail.com> wrote:
>>>>>>>> Wouldn't/shouldn't this be caught in QA? Run through all automated
>>>>>>>> and manual tests. Dynamic index count should be zero.
>>>>>>>> If I didn't catch in QA, i'd rather get a warning, if anything,
>>>>>>>> rather than blow up production. My wager would be that- if it was missed by
>>>>>>>> QA, the dynamic index would be in something with lower impact which
>>>>>>>> wouldn't cause too many problems.
>>>>>>>> On Jul 10, 2012 8:09 AM, "Chris Marisic" <ch...@marisic.com>
>>>>>>>> wrote:
>>>>>>>>> Total control over indexes, i never want an index randomly created
>>>>>>>>> in production. I'd rather it fail, than compile a whole index.
>>>>>>>>> On Tuesday, July 10, 2012 1:28:59 AM UTC-4, Oren Eini wrote:
>>>>>>>>>> Currently,no.
>>>>>>>>>> Can you explain why you want to do this?
>>>>>>>>>> On Mon, Jul 9, 2012 at 10:53 PM, Ken Dale <k...@kendaleiv.com>wrote:
