var user1 = session.Query<User>().FirstOrDefault(u =>
u.FullName == "Ben Foster"); // returns user
var user2 = session.Query<User>().FirstOrDefault(u =>
u.FullName.Equals("Ben Foster")); // returns null
var user3 = session.Query<User>().FirstOrDefault(u =>
u.FullName.Equals("Ben Foster", StringComparison.Ordinal)); // returns
null
var user4 = session.Query<User>().FirstOrDefault(u =>
u.FullName.Equals("Ben Foster",
StringComparison.InvariantCultureIgnoreCase)); // returns user
Is this something to do with the Linq provider as I thought the ==
operator, Equals(string, string) and Equals(string,
StringComparison.Ordinal) effectively did the same thing?
On Fri, May 4, 2012 at 1:57 AM, Ben <b...@planetcloud.co.uk> wrote:
> Hi,
> Given the following document:
> {
> "FullName": "Ben Foster",
> }
> The following occurs:
> var user1 = session.Query<User>().FirstOrDefault(u =>
> u.FullName == "Ben Foster"); // returns user
> var user2 = session.Query<User>().FirstOrDefault(u =>
> u.FullName.Equals("Ben Foster")); // returns null
> var user3 = session.Query<User>().FirstOrDefault(u =>
> u.FullName.Equals("Ben Foster", StringComparison.Ordinal)); // returns
> null
> var user4 = session.Query<User>().FirstOrDefault(u =>
> u.FullName.Equals("Ben Foster",
> StringComparison.InvariantCultureIgnoreCase)); // returns user
> Is this something to do with the Linq provider as I thought the ==
> operator, Equals(string, string) and Equals(string,
> StringComparison.Ordinal) effectively did the same thing?
It's redudant to support Equals(string, StringComparison) because all of those comparisons could be facilitated by using an appropriate Lucene analyzer for the field, correct?
On Friday, May 4, 2012 9:49:28 AM UTC-4, Oren Eini wrote:
> Ben, > we don't support Equals(string, StringComparison)
> On Fri, May 4, 2012 at 1:57 AM, Ben <b...@planetcloud.co.uk> wrote:
>> Hi,
>> Given the following document:
>> { >> "FullName": "Ben Foster", >> }
>> The following occurs:
>> var user1 = session.Query<User>().FirstOrDefault(u => >> u.FullName == "Ben Foster"); // returns user >> var user2 = session.Query<User>().FirstOrDefault(u => >> u.FullName.Equals("Ben Foster")); // returns null >> var user3 = session.Query<User>().FirstOrDefault(u => >> u.FullName.Equals("Ben Foster", StringComparison.Ordinal)); // returns >> null >> var user4 = session.Query<User>().FirstOrDefault(u => >> u.FullName.Equals("Ben Foster", >> StringComparison.InvariantCultureIgnoreCase)); // returns user
>> Is this something to do with the Linq provider as I thought the == >> operator, Equals(string, string) and Equals(string, >> StringComparison.Ordinal) effectively did the same thing?
On Fri, May 4, 2012 at 5:12 PM, Chris Marisic <ch...@marisic.com> wrote:
> It's redudant to support Equals(string, StringComparison) because all
> of those comparisons could be facilitated by using an appropriate Lucene
> analyzer for the field, correct?
> On Friday, May 4, 2012 9:49:28 AM UTC-4, Oren Eini wrote:
>> Ben,
>> we don't support Equals(string, StringComparison)
>> On Fri, May 4, 2012 at 1:57 AM, Ben <b...@planetcloud.co.uk> wrote:
>>> Hi,
>>> Given the following document:
>>> {
>>> "FullName": "Ben Foster",
>>> }
>>> The following occurs:
>>> var user1 = session.Query<User>().**FirstOrDefault(u =>
>>> u.FullName == "Ben Foster"); // returns user
>>> var user2 = session.Query<User>().**FirstOrDefault(u =>
>>> u.FullName.Equals("Ben Foster")); // returns null
>>> var user3 = session.Query<User>().**FirstOrDefault(u =>
>>> u.FullName.Equals("Ben Foster", StringComparison.Ordinal)); // returns
>>> null
>>> var user4 = session.Query<User>().**FirstOrDefault(u =>
>>> u.FullName.Equals("Ben Foster",
>>> StringComparison.**InvariantCultureIgnoreCase)); // returns user
>>> Is this something to do with the Linq provider as I thought the ==
>>> operator, Equals(string, string) and Equals(string,
>>> StringComparison.Ordinal) effectively did the same thing?
> On Fri, May 4, 2012 at 5:12 PM, Chris Marisic <ch...@marisic.com> wrote:
> > It's redudant to support Equals(string, StringComparison) because all
> > of those comparisons could be facilitated by using an appropriate Lucene
> > analyzer for the field, correct?
> > On Friday, May 4, 2012 9:49:28 AM UTC-4, Oren Eini wrote:
> >> Ben,
> >> we don't support Equals(string, StringComparison)
> >> On Fri, May 4, 2012 at 1:57 AM, Ben <b...@planetcloud.co.uk> wrote:
> >>> Is this something to do with the Linq provider as I thought the ==
> >>> operator, Equals(string, string) and Equals(string,
> >>> StringComparison.Ordinal) effectively did the same thing?
> So by default we are always case insensitive? I'm assuming I need to > create an index for this then?
> On May 4, 3:19 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com> > wrote: > > Yes
> > On Fri, May 4, 2012 at 5:12 PM, Chris Marisic <ch...@marisic.com> > wrote: > > > It's redudant to support Equals(string, StringComparison) because > all > > > of those comparisons could be facilitated by using an appropriate > Lucene > > > analyzer for the field, correct?
> > > On Friday, May 4, 2012 9:49:28 AM UTC-4, Oren Eini wrote:
> > >> Ben, > > >> we don't support Equals(string, StringComparison)
> > >> On Fri, May 4, 2012 at 1:57 AM, Ben <b...@planetcloud.co.uk> wrote:
> > >>> Is this something to do with the Linq provider as I thought the == > > >>> operator, Equals(string, string) and Equals(string, > > >>> StringComparison.Ordinal) effectively did the same thing?
