Cannot convert type 'string' to 'System.DateTime' when create index to ravendb2.5

[Tim Zhang]

The following is my Test file,when I run test I got the following error,can you point what the issue is ?

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

public class IR_PlanOfServicec_Test : RavenTestBase

{

        #region PlanOfService

public class PlanOfService

        {

            public PlanOfService()

            {

            }

            public DateTimeOffset CreatedDate { get;  set; }

        

            public DateTimeOffset? EffectiveDate { get;  set; }

        

            public DateTimeOffset? EndDate { get;  set; }

        

            public string Id { get; private set; }

        

        } 

  #endregion

        public class IR_Waiver_PlanOfService : AbstractIndexCreationTask<PlanOfService>

        {

            public IR_Waiver_PlanOfService()

            {

                Map = planofservices => from planofservice in planofservices

                                        select new

                                        {

                                            Id = planofservice.Id,

                                            CreatedDate = planofservice.CreatedDate <= DateTime.Parse("1/1/1900") ? (DateTime?)null : planofservice.CreatedDate.DateTime,

                                            EffectiveDate = planofservice.EffectiveDate <= DateTime.Parse("1/1/1900") ? (DateTime?)null : planofservice.EffectiveDate.GetValueOrDefault().DateTime,

                                            EndDate = planofservice.EndDate <= DateTime.Parse("1/1/1900") ? (DateTime?)null : planofservice.EndDate.GetValueOrDefault().DateTime,

                                        };

            }

            

        }

[Fact]

public void TestIndex()

{

using (var store = NewDocumentStore())

{

using (var session = store.OpenSession())

{

session.Store(new  PlanOfService { CreatedDate = DateTime.Now, EffectiveDate = DateTime.Now, EndDate = DateTime.Now});

session.SaveChanges();

}

                new IR_Waiver_PlanOfService().Execute(store);

using (var session = store.OpenSession())

{

                    var results = session.Query<PlanOfService, IR_Waiver_PlanOfService>()

                    .Customize(customization => customization.WaitForNonStaleResults())

                    .ToList();

Assert.Empty(store.DatabaseCommands.GetStatistics().Errors);

Assert.Equal(1, results.Count);

}

}

}

}

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Tim Zhang]

seems change the EffectiveDate and EndDate  in the index to the following can resolve the issue but don't know why?

 

EffectiveDate = planofservice.EffectiveDate.GetValueOrDefault()<= DateTime.Parse("1/1/1900") ? (DateTime?)null : planofservice.EffectiveDate,

   EndDate = planofservice.EndDate.GetValueOrDefault()<= DateTime.Parse("1/1/1900") ? (DateTime?)null : planofservice.EndDate,

[Matt Johnson]

What are you actually trying to accomplish here?  None of the items you are indexing are actually used in your query.

If the idea is that you might later filter or sort by these columns, you should probably just index them directly.

Map = planofservices =>
    from planofservice in planofservices
    select new

            {
                planofservice.CreatedDate,
                planofservice.EffectiveDate,
                planofservice.EndDate
            };

There isn't much point in adjusting the indexed values during indexing unless you truly have a need to transform them (such as with time zones).  And you don't need to index the Id, it's always included automatically.

Also, this is just being nitpicky, but try to avoid multiple calls to DateTime.Now, since you could have variations in milliseconds/nanoseconds between calls, which could throw you off later.  Instead, call it once and put it in a local variable to re-use as needed.  And preferably, since these are DateTimeOffset values, you should use DateTimeOffset.Now or DateTimeOffset.UtcNow.

-Matt 

[Michael Yarichuk]

Hi,

I think it may be an issue. This index definition should not cause any compilation errors.

So far I see problem with DateTime.Parse("1/1/1900") statement --> it is not compiled correctly at the server-side. 

I will look into this.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Best regards,

 

Michael Yarichuk

RavenDB Core Team

Tel: 972-4-6227811

Fax:972-153-4-6227811

Email : michael....@hibernatingrhinos.com

 

[Fitzchak Yitzchaki]

The issue here that the linq compiler compiles your code to the following: Convert(Convert(Convert("1/1/1900")))). I think that in this case, instead of casting the string to DateTime which is not valid, we can assume that we need to use DateTime.Parse(stringConstant).

Best Regards,

Fitzchak Yitzchaki

Hibernating Rhinos Core Team

Tel: +972-4-6227811

Fax: +972-153-4-6227811

Email: fitz...@hibernatingrhinos.com

[Fitzchak Yitzchaki]

I fixed it, https://github.com/fitzchak/ravendb/commit/32d040191eb2ded978387e4b0660e013cb4230ba, now running the tests to see if something else broke.

Best Regards,

Fitzchak Yitzchaki

Hibernating Rhinos Core Team

Tel: +972-4-6227811

Fax: +972-153-4-6227811

Email: fitz...@hibernatingrhinos.com

[Matt Johnson]

If you're going to do that for DateTime.Parse, you will also need to handle DateTime.ParseExact, DateTimeOffset.Parse, DateTimeOffset.ParseExact, TimeSpan.Parse, TimeSpan.ParseExact, and who knows what else.

I'd probably say you won't need the TryParseExact variants, since there's no good way to use an output parameter in a LINQ query.

I'm still not sure why this is necessary.  Shouldn't it just be plain C# code at that point?  Besides, you really don't want to be parsing m/d/yyyy or d/m/yyyy format anyway.  Either parse yyyy-mm-dd or just do new Date(1900,1,1)

Anyway - none of this addresses the fact that the index isn't meaningful anyway.  Again, Tim Zhang, what are you trying to do?

[Fitzchak Yitzchaki]

I wasn't able to made the other type of x.Parse to fail. I tried implicit conversion of long.Parse and short.Parse into nullable int, but it worked. Also I tried with DateTimeOffset.Parse to nullable DateTimeOffset and it worked. So I guess that this is a very special case, because of the 3 implicit conversion: DateTime to DateTimeOffset To DateTimeOffset?.

Best Regards,

Fitzchak Yitzchaki

Hibernating Rhinos Core Team

Tel: +972-4-6227811

Fax: +972-153-4-6227811

Email: fitz...@hibernatingrhinos.com

[Tim Zhang]

Because I used this index for replication and there are some business rule to restrict the Date.

[Chris Marisic]

On Sunday, November 17, 2013 6:38:21 PM UTC-5, Matt Johnson wrote:

There isn't much point in adjusting the indexed values during indexing unless you truly have a need to transform them (such as with time zones).  And you don't need to index the Id, it's always included automatically.

That's not necessarily true. If you expect to access .Id as a projection you need the .Id field in the index and stored. Unless they fixed this at some point, but it was one of the first issues i encountered in attempting to upgrade from 960 to 2.5, indexes that were returning nulls in Id because the field wasn't explicitly mapped and stored.

[Matt Johnson]

Interesting...  I had thought Id was always stored, so that it could use it to load the document.  But perhaps it's stored in a different location so projections can't locate it unless you store explicitly.  I would think this is something that could be "fixed".

[Matt Johnson]

Hi Tim.  Can you elaborate on that?  If you mean that you want to restrict *by* the date, consider adding a .Where clause to your map to filter, rather than on each item.  You don't want a bunch of index entries with nulls laying around.

[Oren Eini (Ayende Rahien)]

Yes, the document is is always stored.

Oren Eini

CEO

Hibernating Rhinos

Cellular: +972-52-548-6969

Office:    +972-4-674-7811

Fax:       +972-153-4622-7811

--

[Kijana Woodard]

I guess there's some friction as to how to access the Id in various scenarios: index projections, scripted patch, SIR, ...

[Matt Johnson]

I did some tests, and it does appear that Id comes through on projections even if you don't store it, or even if you explicitly say NOT to store it, it does anyway, which is probably good.

https://gist.github.com/mj1856/7608183

[Matt Johnson]

Also ran the tests on multiple versions.  2750, 2666, 2599, 2230 and all pass.  If it ever didn't work, then it must have been much earlier in the history, or some specific regression that was repaired.

[Kijana Woodard]

Hmmm. Good to know.

[Kijana Woodard]

Thanks for doing these.

How were you able to test the different versions so fast? Branches?

[Matt Johnson]

Nope.  Just nuget uninstall and reinstall of RavenDB.Tests.Helpers and dependencies within my test project, using the -Version flag.

[Kijana Woodard]

I'm thinking about a way to keep branches for various versions against a suite of tests for automated regressions. User contrib tests of actual usage, as opposed to expected/tested usage, would be good too.