ita...@hibernatingrhinos.com> wrote: > Compiling JSON.NET into Raven.Json?
> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> 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> 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?
aye...@ayende.com> wrote: > Yeah, I am not really sure that I want to _do_ that.
> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < > ita...@hibernatingrhinos.com> wrote:
>> Compiling JSON.NET into Raven.Json?
>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> 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> 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?
One of the things that drive me crazy right now with json.net is that he adds abstract methods to things like JsonReader, which means that even with assembly redirect, you would get MethondNotFoundException
On Sun, Apr 15, 2012 at 2:51 PM, Itamar Syn-Hershko <
ita...@hibernatingrhinos.com> wrote: > Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..
> Why can't this be resolved with assembly redirects, btw?
> On Sun, Apr 15, 2012 at 2:49 PM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
>> Yeah, I am not really sure that I want to _do_ that.
>> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < >> ita...@hibernatingrhinos.com> wrote:
>>> Compiling JSON.NET into Raven.Json?
>>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> 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> 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 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> 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've used the before to make sure different version of a dll is used under > XP compared to Vista.
> 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> 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 was going to bring up this exact topic. I've been considering the remaining dependencies and references when one references the RavenDB.Client & RavenDB.Embedded packages. Currently focusing on logging right now.
I think this is the only direction you can go... You can't ILMerge /internalize because types are exported via Raven.Abstractions etc and the user will end up with namespace collisions and type ambiguity.
On Sunday, 15 April 2012 12:49:06 UTC+1, Oren Eini wrote:
> Yeah, I am not really sure that I want to _do_ that.
> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < > ita...@hibernatingrhinos.com> wrote:
>> Compiling JSON.NET into Raven.Json?
>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> 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> 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've used the before to make sure different version of a dll is used under > XP compared to Vista.
> 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> 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've taken a similar approach with the logging abstraction but that is a simple interface.
> assembly redirects
A fragile hack, imho, which can (often) result in runtime exceptions. Json.Net is such a critical part of Raven, if it were up to me, I wouldn't want to rely on that and the support issues that can (and will) arise from that.
Unless your CI runs your tests against all published versions of JSON.net.
On Sunday, 15 April 2012 12:51:46 UTC+1, Itamar Syn-Hershko wrote:
> Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..
> Why can't this be resolved with assembly redirects, btw?
> On Sun, Apr 15, 2012 at 2:49 PM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
>> Yeah, I am not really sure that I want to _do_ that.
>> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < >> ita...@hibernatingrhinos.com> wrote:
>>> Compiling JSON.NET into Raven.Json?
>>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> 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> 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 Sun, Apr 15, 2012 at 4:39 PM, Damian Hickey <dhic...@gmail.com> wrote: > I've taken a similar approach with the logging abstraction but that is a > simple interface.
> > assembly redirects
> A fragile hack, imho, which can (often) result in runtime exceptions. > Json.Net is such a critical part of Raven, if it were up to me, I wouldn't > want to rely on that and the support issues that can (and will) arise from > that.
> Unless your CI runs your tests against all published versions of JSON.net.
> On Sunday, 15 April 2012 12:51:46 UTC+1, Itamar Syn-Hershko wrote:
>> Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..
>> Why can't this be resolved with assembly redirects, btw?
>> On Sun, Apr 15, 2012 at 2:49 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> wrote:
>>> Yeah, I am not really sure that I want to _do_ that.
>>> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < >>> ita...@hibernatingrhinos.com> wrote:
>>>> Compiling JSON.NET into Raven.Json?
>>>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >>>> aye...@ayende.com> 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> 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?
OK I will try this out again.
Couple of months ago I had to create a static index with sort order,
because a dynamic index OrderBy would always sort alphabetically.
It is great if this has been fixed since then!
> Alwin,
> when you do OrderBy / OrderByDescending in the Linq API, that works.
> On Sat, Apr 14, 2012 at 4:08 AM, alwin <alw...@gmail.com> wrote:
> > It would be great if numbers would sort as numbers by default, and not
> > as text.
> > OrderBy(a number) would then become consistent with the default
> > ordering of numbers.
> > The current behavior is counter-intuitive.
> > On Apr 10, 11: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?
I've recently added a comment regarding this on RavenDB-178.
I am of the opinion that true semver is a fallacy on .net. Just about every change is potentially a breaking one. And then include internal behaviour that can break, even if API doesn't change. There isn't the tooling in .net to easily detect and catch these breaks. Perhaps with NDepend, but not widely used.
At this point I think your options are:
A) Rely on json.net semantic versioning and depend on patch range, but also set up CI configuration to build against all published versions within this patch range. This reduces friction for customers but only until the next minor release of json.net. It's pragmatic because you will catch inadvertent breaking changes before your customers (and support line) does.
B) Import the json.net code base and re-namespace. Opens up the possibility of incompatibility between serializers. I can't say how big a prob that could end up being. Off the top of my head, ServiceStack took this approach with it's FluentValidation dependency.
It's a difficult problem. I too would love any betters idees.
Fyi, my experience in this area is a software product that has dependency on 60+ oss packages and counting (not all in one project obviously) and I'm experiencing this 'diamond' dependency pain on a near daily basis. Thus, my recent contributions to Raven's packaging, dependency and deployment story.
On Sunday, 15 April 2012 12:57:21 UTC+1, Oren Eini wrote:
> One of the things that drive me crazy right now with json.net is that he > adds abstract methods to things like JsonReader, which means that even with > assembly redirect, you would get MethondNotFoundException
> On Sun, Apr 15, 2012 at 2:51 PM, Itamar Syn-Hershko < > ita...@hibernatingrhinos.com> wrote:
>> Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..
>> Why can't this be resolved with assembly redirects, btw?
>> On Sun, Apr 15, 2012 at 2:49 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> wrote:
>>> Yeah, I am not really sure that I want to _do_ that.
>>> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < >>> ita...@hibernatingrhinos.com> wrote:
>>>> Compiling JSON.NET into Raven.Json?
>>>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >>>> aye...@ayende.com> 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> 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?
> Damian, > JSON.Net is actually pretty much use everywhere inside RavenDB.
> On Sun, Apr 15, 2012 at 4:39 PM, Damian Hickey <dhic...@gmail.com> wrote:
>> I've taken a similar approach with the logging abstraction but that is a >> simple interface.
>> > assembly redirects
>> A fragile hack, imho, which can (often) result in runtime exceptions. >> Json.Net is such a critical part of Raven, if it were up to me, I wouldn't >> want to rely on that and the support issues that can (and will) arise from >> that.
>> Unless your CI runs your tests against all published versions of JSON.net.
>> On Sunday, 15 April 2012 12:51:46 UTC+1, Itamar Syn-Hershko wrote:
>>> Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..
>>> Why can't this be resolved with assembly redirects, btw?
>>> On Sun, Apr 15, 2012 at 2:49 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> wrote:
>>>> Yeah, I am not really sure that I want to _do_ that.
>>>> On Sun, Apr 15, 2012 at 2:47 PM, Itamar Syn-Hershko < >>>> ita...@hibernatingrhinos.com> wrote:
>>>>> Compiling JSON.NET into Raven.Json?
>>>>> On Sun, Apr 15, 2012 at 2:44 PM, Oren Eini (Ayende Rahien) < >>>>> aye...@ayende.com> 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> 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 meant, for indexing purposes, we would index the UTC time, and search on
> UTC time.
> We would save the _document_ as local time.
YES - that would work very well. I would make the following
assumptions:
If I store a DateTime without an offset such as "2012-04-15T10:00:00"
that it would be saved and indexed without any conversion.
If I store a DateTimeOffset such as "2012-04-15T10:00:00-07:00" that
it would be saved in the document without conversion, but would be
indexed as UTC "2012-04-15T17:00:00Z".
When I query an index by a DateTimeOffset, that the query engine would
adjust input parameters to UTC before comparing against the index, so
I don't have to think too much about what's happening behind the
scenes.
That all of this would depend on something like
Indexing.SortOptions.DateTimeOffset, which would be the default when
using this datatype.
> What is the meaning on sorting on different times in different time zones?
This is how it ends up working today due to the lexicographical sort.
The only use case is when you want the search to be ignorant of the
timezone. There aren't very many scenarios that require that. The
other method would be much better. If the SortOptions is selectable,
this behavior could still be used if SortOptions.String was selected
instead.
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> 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?
> 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> 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?
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:
> 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?
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/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 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/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?
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/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 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/**Newtonsoft.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 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/**Newtonsoft.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?
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 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/**Newtonsoft.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?
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?
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?
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.
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?
