ita...@hibernatingrhinos.com> wrote: > Why does the internaling process have to involve changing the namespace?
> We can compile the sources using their original namespaces into > Raven.Json, which in turn has its own wrappers around it, which we use. The > change will be transparent.
> On Tue, Apr 17, 2012 at 3:24 PM, Fitzchak Yitzchaki < > fitzc...@hibernatingrhinos.com> wrote:
>> James (the creator of Json.NET) points out the internaling the Json.NET >> code will result in the following breaking change: >> Any reference to JsonIgnore, JsonProperty, JsonConvert, JsonObject, >> JsonArray attributes (and maybe more) would break and the user will be >> required to use the internal namespace of this attributes. (Which will be >> like Raven.Internal.Newtonsoft.Json).
>> Well this is a breaking change, which we didn't took into account >> initially. What do you think about it?
>> On Mon, Apr 16, 2012 at 7:23 PM, Damian Hickey <dhic...@gmail.com> wrote:
>>> Nice. I did a powershell script to alter the assembly with cecil >>> (nothing new there) but this would be could be better in long run, >>> especially with respect to debugging.
>>> On Monday, 16 April 2012 11:46:23 UTC+1, Fitzchak Yitzchaki wrote:
>>>> On Mon, Apr 16, 2012 at 1:28 PM, Damian Hickey <dhic...@gmail.com>wrote:
>>>>> That'll should allow you to import the source all right. I'm very >>>>> interested to see how you maintain the namespace and related changes on top >>>>> of that. (I'm presuming you'll still need to maintain some sort of fork.)
>>>>> I might flesh out my idea a bit more, as a matter of personal interest.
>>>>> On Monday, 16 April 2012 09:43:52 UTC+1, Oren Eini wrote:
>>>>>> Right now we are testing if we can just import the code using git >>>>>> subtree and that would work.
>>>>>> On Mon, Apr 16, 2012 at 11:37 AM, Damian Hickey <dhic...@gmail.com>wrote:
>>>>>>> This is just basically IL rewriting. Other IL rewriters >>>>>>> (ccrewrite/ilmerge/etc) seem to handle pdbs just fine.
>>>>>>> I actually spiked out your approach first (see >>>>>>> https://github.com/damianh/**New**tonsoft.Json/tree/Ravenize<https://github.com/damianh/Newtonsoft.Json/tree/Ravenize>) and while it sorta worked, there are some items that will bump the >>>>>>> maintenance cost of doing so such as merging (as you mentioned), edge cases >>>>>>> in string literals (InternalsVisibleTo, DynamicWrapper.cs), strong names, >>>>>>> and ensuring that the tests pass. That was just what I encountered last >>>>>>> night.
>>>>>>> What appealed to me about the IL rewrite approach is that you're >>>>>>> taking a released and tested assembly and just re-namespacing. It simpler >>>>>>> maintenance wise, but it could be deceptive and broken in actual usage.
>>>>>>> The third approach is to import the json.net code base, including >>>>>>> tests, into the Raven repo and create a script to periodically synchronize >>>>>>> changes.
>>>>>>> I don't yet know which is the better approach. Each one has >>>>>>> advantages and trade-offs. Further exploration required.
>>>>>>> On Monday, 16 April 2012 07:55:29 UTC+1, Tobi wrote:
>>>>>>>> Wouldn't this terribly break the debugging symbols?
>>>>>>>> Why not just take the Newtonsoft.Json source, replace the >>>>>>>> namespaces with >>>>>>>> a script and add the changed source to RavenDB. On the next >>>>>>>> Newtonsoft.Json release just run the same script on the new sources.
>>>>>>>> It might even be feasible to maintain a fork from >>>>>>>> https://github.com >>>>>>>> /JamesNK/Newtonsoft.Json. Possible merge conflicts shouldn't be to >>>>>>>> hard to >>>>>>>> resolve if only the namespaces are changed.
>>>>>>>> On 16.04.2012 08:02, Oren Eini (Ayende Rahien) wrote:
>>>>>>>> > Yeah, I am not sure how much I like it, but yeah, we might just >>>>>>>> end up >>>>>>>> > doing this.
>>>>>>>> > On Sun, Apr 15, 2012 at 10:53 PM, Damian Hickey < >>>>>>>> dhic...@gmail.com >>>>>>>> > <mailto:dhic...@gmail.com>> wrote:
>>>>>>>> > Just did this manually and it appears Raven.Json.dll turned >>>>>>>> out ok >>>>>>>> > when browsed in ILSpy and referenced in a csproj.
>>>>>>>> > Could be feasible if you never need to fork NewtonSoft.Json?
>>>>>>>> > On Sunday, 15 April 2012 12:44:45 UTC+1, Oren Eini wrote:
>>>>>>>> > Another thing that I want to try it to see if we can >>>>>>>> internalize >>>>>>>> > our own Json.NET dependency. >>>>>>>> > It causes some non trivial amount of friction for users, >>>>>>>> it seems. >>>>>>>> > I am not sure how to do this yet, but I would love to get >>>>>>>> some ideas.
>>>>>>>> > On Tue, Apr 10, 2012 at 12:45 PM, Oren Eini (Ayende >>>>>>>> Rahien) >>>>>>>> > <aye...@ayende.com <mailto:aye...@ayende.com>> wrote:
>>>>>>>> > We are _considering_ some breaking changes to 1.2
>>>>>>>> > In particular, there are some things that I don't >>>>>>>> like in the >>>>>>>> > way we are handling dates in indexes, and a bunch of >>>>>>>> other >>>>>>>> > relatively minor stuff, which we can't current do due >>>>>>>> to >>>>>>>> > backward compatibility.
>>>>>>>> > That led me to think that there are probably >>>>>>>> additional stuff >>>>>>>> > that you are probably gnashing your teeth about that >>>>>>>> we can't >>>>>>>> > fix because of backward compact.
>>>>>>>> > Does anyone have major things that they want to >>>>>>>> change in the >>>>>>>> > way RavenDB works?
On Tue, Apr 17, 2012 at 3:36 PM, Tom Cabanski <t...@cabanski.com> wrote: > This kind of breaking change would cause all sorts of problems. I really > think you are better off leaving external references external as a general > rule.
> On Tue, Apr 17, 2012 at 7:24 AM, Fitzchak Yitzchaki < > fitzc...@hibernatingrhinos.com> wrote:
>> James (the creator of Json.NET) points out the internaling the Json.NET >> code will result in the following breaking change: >> Any reference to JsonIgnore, JsonProperty, JsonConvert, JsonObject, >> JsonArray attributes (and maybe more) would break and the user will be >> required to use the internal namespace of this attributes. (Which will be >> like Raven.Internal.Newtonsoft.Json).
>> Well this is a breaking change, which we didn't took into account >> initially. What do you think about it?
>> On Mon, Apr 16, 2012 at 7:23 PM, Damian Hickey <dhic...@gmail.com> wrote:
>>> Nice. I did a powershell script to alter the assembly with cecil >>> (nothing new there) but this would be could be better in long run, >>> especially with respect to debugging.
>>> On Monday, 16 April 2012 11:46:23 UTC+1, Fitzchak Yitzchaki wrote:
>>>> On Mon, Apr 16, 2012 at 1:28 PM, Damian Hickey <dhic...@gmail.com>wrote:
>>>>> That'll should allow you to import the source all right. I'm very >>>>> interested to see how you maintain the namespace and related changes on top >>>>> of that. (I'm presuming you'll still need to maintain some sort of fork.)
>>>>> I might flesh out my idea a bit more, as a matter of personal interest.
>>>>> On Monday, 16 April 2012 09:43:52 UTC+1, Oren Eini wrote:
>>>>>> Right now we are testing if we can just import the code using git >>>>>> subtree and that would work.
>>>>>> On Mon, Apr 16, 2012 at 11:37 AM, Damian Hickey <dhic...@gmail.com>wrote:
>>>>>>> This is just basically IL rewriting. Other IL rewriters >>>>>>> (ccrewrite/ilmerge/etc) seem to handle pdbs just fine.
>>>>>>> I actually spiked out your approach first (see >>>>>>> https://github.com/damianh/**New**tonsoft.Json/tree/Ravenize<https://github.com/damianh/Newtonsoft.Json/tree/Ravenize>) and while it sorta worked, there are some items that will bump the >>>>>>> maintenance cost of doing so such as merging (as you mentioned), edge cases >>>>>>> in string literals (InternalsVisibleTo, DynamicWrapper.cs), strong names, >>>>>>> and ensuring that the tests pass. That was just what I encountered last >>>>>>> night.
>>>>>>> What appealed to me about the IL rewrite approach is that you're >>>>>>> taking a released and tested assembly and just re-namespacing. It simpler >>>>>>> maintenance wise, but it could be deceptive and broken in actual usage.
>>>>>>> The third approach is to import the json.net code base, including >>>>>>> tests, into the Raven repo and create a script to periodically synchronize >>>>>>> changes.
>>>>>>> I don't yet know which is the better approach. Each one has >>>>>>> advantages and trade-offs. Further exploration required.
>>>>>>> On Monday, 16 April 2012 07:55:29 UTC+1, Tobi wrote:
>>>>>>>> Wouldn't this terribly break the debugging symbols?
>>>>>>>> Why not just take the Newtonsoft.Json source, replace the >>>>>>>> namespaces with >>>>>>>> a script and add the changed source to RavenDB. On the next >>>>>>>> Newtonsoft.Json release just run the same script on the new sources.
>>>>>>>> It might even be feasible to maintain a fork from >>>>>>>> https://github.com >>>>>>>> /JamesNK/Newtonsoft.Json. Possible merge conflicts shouldn't be to >>>>>>>> hard to >>>>>>>> resolve if only the namespaces are changed.
>>>>>>>> On 16.04.2012 08:02, Oren Eini (Ayende Rahien) wrote:
>>>>>>>> > Yeah, I am not sure how much I like it, but yeah, we might just >>>>>>>> end up >>>>>>>> > doing this.
>>>>>>>> > On Sun, Apr 15, 2012 at 10:53 PM, Damian Hickey < >>>>>>>> dhic...@gmail.com >>>>>>>> > <mailto:dhic...@gmail.com>> wrote:
>>>>>>>> > Just did this manually and it appears Raven.Json.dll turned >>>>>>>> out ok >>>>>>>> > when browsed in ILSpy and referenced in a csproj.
>>>>>>>> > Could be feasible if you never need to fork NewtonSoft.Json?
>>>>>>>> > On Sunday, 15 April 2012 12:44:45 UTC+1, Oren Eini wrote:
>>>>>>>> > Another thing that I want to try it to see if we can >>>>>>>> internalize >>>>>>>> > our own Json.NET dependency. >>>>>>>> > It causes some non trivial amount of friction for users, >>>>>>>> it seems. >>>>>>>> > I am not sure how to do this yet, but I would love to get >>>>>>>> some ideas.
>>>>>>>> > On Tue, Apr 10, 2012 at 12:45 PM, Oren Eini (Ayende >>>>>>>> Rahien) >>>>>>>> > <aye...@ayende.com <mailto:aye...@ayende.com>> wrote:
>>>>>>>> > We are _considering_ some breaking changes to 1.2
>>>>>>>> > In particular, there are some things that I don't >>>>>>>> like in the >>>>>>>> > way we are handling dates in indexes, and a bunch of >>>>>>>> other >>>>>>>> > relatively minor stuff, which we can't current do due >>>>>>>> to >>>>>>>> > backward compatibility.
>>>>>>>> > That led me to think that there are probably >>>>>>>> additional stuff >>>>>>>> > that you are probably gnashing your teeth about that >>>>>>>> we can't >>>>>>>> > fix because of backward compact.
>>>>>>>> > Does anyone have major things that they want to >>>>>>>> change in the >>>>>>>> > way RavenDB works?
fitzc...@hibernatingrhinos.com> wrote: > James (the creator of Json.NET) points out the internaling the Json.NET > code will result in the following breaking change: > Any reference to JsonIgnore, JsonProperty, JsonConvert, JsonObject, > JsonArray attributes (and maybe more) would break and the user will be > required to use the internal namespace of this attributes. (Which will be > like Raven.Internal.Newtonsoft.Json).
> Well this is a breaking change, which we didn't took into account > initially. What do you think about it?
> On Mon, Apr 16, 2012 at 7:23 PM, Damian Hickey <dhic...@gmail.com> wrote:
>> Nice. I did a powershell script to alter the assembly with cecil (nothing >> new there) but this would be could be better in long run, especially with >> respect to debugging.
>> On Monday, 16 April 2012 11:46:23 UTC+1, Fitzchak Yitzchaki wrote:
>>> On Mon, Apr 16, 2012 at 1:28 PM, Damian Hickey <dhic...@gmail.com>wrote:
>>>> That'll should allow you to import the source all right. I'm very >>>> interested to see how you maintain the namespace and related changes on top >>>> of that. (I'm presuming you'll still need to maintain some sort of fork.)
>>>> I might flesh out my idea a bit more, as a matter of personal interest.
>>>> On Monday, 16 April 2012 09:43:52 UTC+1, Oren Eini wrote:
>>>>> Right now we are testing if we can just import the code using git >>>>> subtree and that would work.
>>>>> On Mon, Apr 16, 2012 at 11:37 AM, Damian Hickey <dhic...@gmail.com>wrote:
>>>>>> This is just basically IL rewriting. Other IL rewriters >>>>>> (ccrewrite/ilmerge/etc) seem to handle pdbs just fine.
>>>>>> I actually spiked out your approach first (see >>>>>> https://github.com/damianh/**New**tonsoft.Json/tree/Ravenize<https://github.com/damianh/Newtonsoft.Json/tree/Ravenize>) and while it sorta worked, there are some items that will bump the >>>>>> maintenance cost of doing so such as merging (as you mentioned), edge cases >>>>>> in string literals (InternalsVisibleTo, DynamicWrapper.cs), strong names, >>>>>> and ensuring that the tests pass. That was just what I encountered last >>>>>> night.
>>>>>> What appealed to me about the IL rewrite approach is that you're >>>>>> taking a released and tested assembly and just re-namespacing. It simpler >>>>>> maintenance wise, but it could be deceptive and broken in actual usage.
>>>>>> The third approach is to import the json.net code base, including >>>>>> tests, into the Raven repo and create a script to periodically synchronize >>>>>> changes.
>>>>>> I don't yet know which is the better approach. Each one has >>>>>> advantages and trade-offs. Further exploration required.
>>>>>> On Monday, 16 April 2012 07:55:29 UTC+1, Tobi wrote:
>>>>>>> Wouldn't this terribly break the debugging symbols?
>>>>>>> Why not just take the Newtonsoft.Json source, replace the namespaces >>>>>>> with >>>>>>> a script and add the changed source to RavenDB. On the next >>>>>>> Newtonsoft.Json release just run the same script on the new sources.
>>>>>>> It might even be feasible to maintain a fork from https://github.com >>>>>>> /JamesNK/Newtonsoft.Json. Possible merge conflicts shouldn't be to >>>>>>> hard to >>>>>>> resolve if only the namespaces are changed.
>>>>>>> On 16.04.2012 08:02, Oren Eini (Ayende Rahien) wrote:
>>>>>>> > Yeah, I am not sure how much I like it, but yeah, we might just >>>>>>> end up >>>>>>> > doing this.
>>>>>>> > On Sun, Apr 15, 2012 at 10:53 PM, Damian Hickey <dhic...@gmail.com >>>>>>> > <mailto:dhic...@gmail.com>> wrote:
>>>>>>> > Just did this manually and it appears Raven.Json.dll turned >>>>>>> out ok >>>>>>> > when browsed in ILSpy and referenced in a csproj.
>>>>>>> > Could be feasible if you never need to fork NewtonSoft.Json?
>>>>>>> > On Sunday, 15 April 2012 12:44:45 UTC+1, Oren Eini wrote:
>>>>>>> > Another thing that I want to try it to see if we can >>>>>>> internalize >>>>>>> > our own Json.NET dependency. >>>>>>> > It causes some non trivial amount of friction for users, >>>>>>> it seems. >>>>>>> > I am not sure how to do this yet, but I would love to get >>>>>>> some ideas.
>>>>>>> > On Tue, Apr 10, 2012 at 12:45 PM, Oren Eini (Ayende Rahien) >>>>>>> > <aye...@ayende.com <mailto:aye...@ayende.com>> wrote:
>>>>>>> > We are _considering_ some breaking changes to 1.2
>>>>>>> > In particular, there are some things that I don't like >>>>>>> in the >>>>>>> > way we are handling dates in indexes, and a bunch of >>>>>>> other >>>>>>> > relatively minor stuff, which we can't current do due >>>>>>> to >>>>>>> > backward compatibility.
>>>>>>> > That led me to think that there are probably >>>>>>> additional stuff >>>>>>> > that you are probably gnashing your teeth about that >>>>>>> we can't >>>>>>> > fix because of backward compact.
>>>>>>> > Does anyone have major things that they want to change >>>>>>> in the >>>>>>> > way RavenDB works?
Hey guys, I faced the same problem a some time ago. Check it out it, works for my team fine. The Short story. We are building sites using Sitecore CMS which uses JSON.NET 3.51 (and it not open source and can' be upgraded as it will break everything), also we have Raven JSON.NET 4.0.8 and our libraries uses the JSON.NET 4.5. So we got JSON.NET source changed the build target names like Vodca.Sdk.Newtonsoft.Net and added reference alias not as global (default) but with out name SDK and modified code (example below) . Now If I need a new version to run from JSON.NET I update source rebuild each time. This way i don't need care about changing custom namespaces or joining the changes , no maintenance problem and all three 'JSON.NET' work together :)
extern alias SDK; namespace Vodca { using System.Diagnostics.CodeAnalysis; using SDK::Newtonsoft.Json;
/// <summary> /// The JSON extension methods /// </summary> public static partial class Extensions {
On Tue, Apr 17, 2012 at 4:16 PM, Jim Baltika <baltikaus...@gmail.com> wrote: > Hey guys, > I faced the same problem a some time ago. Check it out it, works for my > team fine. The Short story. We are building sites using Sitecore CMS which > uses JSON.NET 3.51 (and it not open source and can' be upgraded as it > will break everything), also we have Raven JSON.NET 4.0.8 and our > libraries uses the JSON.NET 4.5. So we got JSON.NET source changed the > build target names like Vodca.Sdk.Newtonsoft.Net and added reference > alias not as global (default) but with out name SDK and modified code > (example below) . Now If I need a new version to run from JSON.NET I > update source rebuild each time. This way i don't need care about changing > custom namespaces or joining the changes , no maintenance problem and all > three 'JSON.NET' work together :)
> extern alias SDK; > namespace Vodca > { > using System.Diagnostics.CodeAnalysis; > using SDK::Newtonsoft.Json;
> /// <summary> > /// The JSON extension methods > /// </summary> > public static partial class Extensions > {
On Tuesday, 10 April 2012 10:45:48 UTC+1, Oren Eini wrote:
> We are _considering_ some breaking changes to 1.2
> In particular, there are some things that I don't like in the way we are > handling dates in indexes, and a bunch of other relatively minor stuff, > which we can't current do due to backward compatibility.
> That led me to think that there are probably additional stuff that you are > probably gnashing your teeth about that we can't fix because of backward > compact.
> Does anyone have major things that they want to change in the way RavenDB > works?
On Friday, April 20, 2012, Matt Warren wrote: > What about changing the behaviour when indexing numerial values?
> At the moment if you have an index that contains and int/long/decimal etc, > it's indexed in 2 fields, for instance Age=2 becomes
> 1. Age = 2 > 2. Age_Range = 0x00000002 (depending on type, int,long etc)
> I believe this is so you can do exact comparisions against the "Age" field > and range comparisions against the "Age_Range" fields. For instance:
> - Age:2 > - Age_Range:[0x0000000 TO 0x00000010]
> Why not just store the "_Range" field and then make the Client API convert > "Where(x => x.Age == 2)" into "Age_Range:0x00000002"
> This would save storing 2 fields in the Lucene index, which would save > On Tuesday, 10 April 2012 10:45:48 UTC+1, Oren Eini wrote:
>> We are _considering_ some breaking changes to 1.2
>> In particular, there are some things that I don't like in the way we are >> handling dates in indexes, and a bunch of other relatively minor stuff, >> which we can't current do due to backward compatibility.
>> That led me to think that there are probably additional stuff that you >> are probably gnashing your teeth about that we can't fix because of >> backward compact.
>> Does anyone have major things that they want to change in the way RavenDB >> works?
> It isn't that important and it would break querying in the studio
> On Friday, April 20, 2012, Matt Warren wrote:
>> What about changing the behaviour when indexing numerial values?
>> At the moment if you have an index that contains and int/long/decimal >> etc, it's indexed in 2 fields, for instance Age=2 becomes
>> 1. Age = 2 >> 2. Age_Range = 0x00000002 (depending on type, int,long etc)
>> I believe this is so you can do exact comparisions against the "Age" >> field and range comparisions against the "Age_Range" fields. For instance:
>> - Age:2 >> - Age_Range:[0x0000000 TO 0x00000010]
>> Why not just store the "_Range" field and then make the Client API >> convert "Where(x => x.Age == 2)" into "Age_Range:0x00000002"
>> This would save storing 2 fields in the Lucene index, which would save >> On Tuesday, 10 April 2012 10:45:48 UTC+1, Oren Eini wrote:
>>> We are _considering_ some breaking changes to 1.2
>>> In particular, there are some things that I don't like in the way we are >>> handling dates in indexes, and a bunch of other relatively minor stuff, >>> which we can't current do due to backward compatibility.
>>> That led me to think that there are probably additional stuff that you >>> are probably gnashing your teeth about that we can't fix because of >>> backward compact.
>>> Does anyone have major things that they want to change in the way >>> RavenDB works?
On Tuesday, April 10, 2012 5:45:48 AM UTC-4, Oren Eini wrote:
> We are _considering_ some breaking changes to 1.2
> In particular, there are some things that I don't like in the way we are > handling dates in indexes, and a bunch of other relatively minor stuff, > which we can't current do due to backward compatibility.
> That led me to think that there are probably additional stuff that you are > probably gnashing your teeth about that we can't fix because of backward > compact.
> Does anyone have major things that they want to change in the way RavenDB > works?
I also don't get the naming of "AbstractIndexCreationTask". When going deeper into RavenDB I understand that is an index creation task for RavenDB, but is it something that a user most know? Does a user use it as a task or as an index (the RavenDB documentation talks about index, if I remember correctly)?
Removing the Abstract would be a step in the good direction, I think.
On Saturday, April 14, 2012 8:20:54 PM UTC+2, Itamar Syn-Hershko wrote: > Because it is not a static index, but an index creation task... Maybe the > Abstract word there is a bit too much...
> On Sat, Apr 14, 2012 at 9:17 PM, Matt Johnson <mj1...@hotmail.com> wrote:
>> This is a very minor thing, but I don't get the naming of >> "AbstractIndexCreationTask". Why not just call it something like >> "StaticIndex"?
>> -Matt
>> On Apr 10, 2:45 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com> >> wrote: >> > We are _considering_ some breaking changes to 1.2
>> > In particular, there are some things that I don't like in the way we are >> > handling dates in indexes, and a bunch of other relatively minor stuff, >> > which we can't current do due to backward compatibility.
>> > That led me to think that there are probably additional stuff that you >> are >> > probably gnashing your teeth about that we can't fix because of backward >> > compact.
>> > Does anyone have major things that they want to change in the way >> RavenDB >> > works?
AbstractIndexDefinition, for the server is a creation task but for the developer is a definition.
I like the Abstract prefix because it enforces the fact that you must inherit from it.
.m
_____________________
It's all about trust...
________________________________
From: Itamar Syn-Hershko
Sent: 07/05/2012 16:41
To: ravendb@googlegroups.com
Subject: Re: [RavenDB] Re: The Breaking Changes Wishlist for 1.2
How would you as a user name that thing?
On Mon, May 7, 2012 at 4:07 PM, Rémy van Duijkeren <remy.vanduijke...@gmail.com<mailto:remy.vanduijke...@gmail.com>> wrote:
I also don't get the naming of "AbstractIndexCreationTask". When going deeper into RavenDB I understand that is an index creation task for RavenDB, but is it something that a user most know? Does a user use it as a task or as an index (the RavenDB documentation talks about index, if I remember correctly)?
Removing the Abstract would be a step in the good direction, I think.
On Saturday, April 14, 2012 8:20:54 PM UTC+2, Itamar Syn-Hershko wrote:
Because it is not a static index, but an index creation task... Maybe the Abstract word there is a bit too much...
On Sat, Apr 14, 2012 at 9:17 PM, Matt Johnson <mj1...@hotmail.com<mailto:mj1...@hotmail.com>> wrote:
This is a very minor thing, but I don't get the naming of
"AbstractIndexCreationTask". Why not just call it something like
"StaticIndex"?
> We are _considering_ some breaking changes to 1.2
> In particular, there are some things that I don't like in the way we are
> handling dates in indexes, and a bunch of other relatively minor stuff,
> which we can't current do due to backward compatibility.
> That led me to think that there are probably additional stuff that you are
> probably gnashing your teeth about that we can't fix because of backward
> compact.
> Does anyone have major things that they want to change in the way RavenDB
> works?
remy.vanduijke...@gmail.com> wrote:
> I also don't get the naming of "AbstractIndexCreationTask". When going
> deeper into RavenDB I understand that is an index creation task for
> RavenDB, but is it something that a user most know? Does a user use it as a
> task or as an index (the RavenDB documentation talks about index, if I
> remember correctly)?
> Removing the Abstract would be a step in the good direction, I think.
> On Saturday, April 14, 2012 8:20:54 PM UTC+2, Itamar Syn-Hershko wrote:
>> Because it is not a static index, but an index creation task... Maybe the
>> Abstract word there is a bit too much...
>> On Sat, Apr 14, 2012 at 9:17 PM, Matt Johnson <mj1...@hotmail.com> wrote:
>>> This is a very minor thing, but I don't get the naming of
>>> "AbstractIndexCreationTask". Why not just call it something like
>>> "StaticIndex"?
>>> -Matt
>>> On Apr 10, 2:45 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
>>> wrote:
>>> > We are _considering_ some breaking changes to 1.2
>>> > In particular, there are some things that I don't like in the way we
>>> are
>>> > handling dates in indexes, and a bunch of other relatively minor stuff,
>>> > which we can't current do due to backward compatibility.
>>> > That led me to think that there are probably additional stuff that you
>>> are
>>> > probably gnashing your teeth about that we can't fix because of
>>> backward
>>> > compact.
>>> > Does anyone have major things that they want to change in the way
>>> RavenDB
>>> > works?
For me it would be more logic to call it something like: IndexDefinition, StaticIndex, NamedIndex,...
IndexDefinition would probably be the best description, because your are only describing they index: it's not the index self. In contradiction to Mauro I'm not so found of the Abstract prefix, but that is, I think, a personal thing.
remy.vanduijke...@gmail.com> wrote:
> For me it would be more logic to call it something like: IndexDefinition,
> StaticIndex, NamedIndex,...
> IndexDefinition would probably be the best description, because your are
> only describing they index: it's not the index self. In contradiction to
> Mauro I'm not so found of the Abstract prefix, but that is, I think, a
> personal thing.
> wrote:
> IndexDefinition already exists, it is the... well, definition of the index.
> This is what AICT creates, after all.
> On Tue, May 8, 2012 at 5:02 PM, Rémy van Duijkeren <
> remy.vanduijke...@gmail.com> wrote:
>> For me it would be more logic to call it something like: IndexDefinition,
>> StaticIndex, NamedIndex,...
>> IndexDefinition would probably be the best description, because your are
>> only describing they index: it's not the index self. In contradiction to
>> Mauro I'm not so found of the Abstract prefix, but that is, I think, a
>> personal thing.
The point being that the prefix "Abstract" or the suffix "Base" identify
it as a class that must be inherited. No need to dig through the
documentation to find out that it must be inherited.
--
Bryan Johns
K4GDW
"When plunder becomes a way of life for a group of men living together in
society, they create for themselves in the course of time a legal system
that authorizes it and a moral code that justifies it." --Frederic Bastiat
> -----Original Message-----
> From: ravendb@googlegroups.com [mailto:ravendb@googlegroups.com] On
> Behalf Of Itamar Syn-Hershko
> Sent: Tuesday, May 08, 2012 5:20 PM
> To: ravendb@googlegroups.com
> Subject: Re: [RavenDB] Re: The Breaking Changes Wishlist for 1.2
> The IndexDefinition class should then be the one with the complex
> naming IMO
> On Wed, May 9, 2012 at 1:18 AM, Oren Eini (Ayende Rahien)
> <aye...@ayende.com> wrote:
> IndexDefinition already exists, it is the... well, definition of
> the index.
> This is what AICT creates, after all.
> On Tue, May 8, 2012 at 5:02 PM, Rémy van Duijkeren
> <remy.vanduijke...@gmail.com> wrote:
> For me it would be more logic to call it something like:
> IndexDefinition, StaticIndex, NamedIndex,...
> IndexDefinition would probably be the best description,
> because your are only describing they index: it's not the index self.
> In contradiction to Mauro I'm not so found of the Abstract prefix, but
> that is, I think, a personal thing.
On Wednesday, May 9, 2012 12:19:50 AM UTC+2, Itamar Syn-Hershko wrote:
> The IndexDefinition class should then be the one with the complex naming > IMO
I grant that :o). Or call it the next one in my list: StaticIndex...
I am mentioning this, just like Matt, because it throw me off, the first few times I had to use it. I think this is because of the following reasons: - Coming from SQL Server, I don't see the connection with Indexes to Tasks. - When creating Task, I expect them to run, but the method for RavenDB is CreateIndexes(Task)...
Also only after reading the post of Gamlor (I first read the RavenDB docs) I was understanding RavenDB (really great and fun explanation!). The post http://www.gamlor.info/wordpress/2011/07/ravendb-queries-and-indexes/ is talking about Dynamic- and StaticIndexes and then I right away get the concept.
Something that really bothers me is DateTime serialization, I would like RavenDb to treat DateTime as SQL Server does, not timezone or DateTimeKind information, therefore DateTime values retrieved from RavenDb correctly have Kind = DateTimeKind.Unspecified.
> -----Original Message-----
> From: ravendb@googlegroups.com [mailto:ravendb@googlegroups.com] On
> Behalf Of Justin A
> DateTime is always UTC dates for me. Simple.
Perfectly reasonable when your users, or data points, need a common date
time reference that spans time zones. However, if the user base is limited
to a single time zone and is unlikely to ever expand beyond that, having to
convert to or from UTC with every read or write is a little unnecessary
overhead. Sure, it's not much, but when you're running on commodity
hardware those little bits add up.
--
Bryan Johns
K4GDW
"Today, when a concerted effort is made to obliterate this point, it cannot
be repeated too often that the Constitution is a limitation on the
government, not on private individuals -- that it does not prescribe the
conduct of private individuals, only the conduct of the government -- that
it is not a charter for government power, but a charter of the citizen's
protection against the government." --author Ayn Rand (1905-1982)
> > -----Original Message-----
> > From: ravendb@googlegroups.com [mailto:ravendb@googlegroups.com] On
> > Behalf Of Justin A
> > DateTime is always UTC dates for me. Simple.
> Perfectly reasonable when your users, or data points, need a common date
> time reference that spans time zones. However, if the user base is limited
> to a single time zone and is unlikely to ever expand beyond that, having to
> convert to or from UTC with every read or write is a little unnecessary
> overhead. Sure, it's not much, but when you're running on commodity
> hardware those little bits add up.
> --
> Bryan Johns
> K4GDW
> "Today, when a concerted effort is made to obliterate this point, it cannot
> be repeated too often that the Constitution is a limitation on the
> government, not on private individuals -- that it does not prescribe the
> conduct of private individuals, only the conduct of the government -- that
> it is not a charter for government power, but a charter of the citizen's
> protection against the government." --author Ayn Rand (1905-1982)
