Support for NodaTime

[igor-tkachev]

No description provided.

[igor-tkachev]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[linq2dbot]

Test baselines changed by this PR. Don't forget to merge/close baselines PR after this pr merged/closed.

[jogibear9988]

i suggest a optional assembly parameter.
Cause for example we load assemblys in a different way in our application.
And only load assembly if it is null.

[igor-tkachev]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[igor-tkachev]

i suggest a optional assembly parameter. Cause for example we load assemblys in a different way in our application. And only load assembly if it is null.

There is an overload with Type parameter. I think it is enough.

[igor-tkachev]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[igor-tkachev]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MaceWindu]

update to address v5 changes?

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jods4]

Supporting NodaTime without adding a dependency results in quite ugly code.
Wouldn't it be nicer to have a package LinqToDb.NodaTime that adds such support in a straightforward fashion (with a direct dependency on NodaTime)?

The blocker here is the ability to easily define mappings for methods that you can't attribute from outside linq2db core.
There's a similar discussion concerning Regex right now and I made an api proposal: #4392 (comment)

[linq2dbot]

Test baselines changed by this PR. Don't forget to merge/close baselines PR after this pr merged/closed.

[MaceWindu]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MaceWindu]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MaceWindu]

@igor-tkachev , @sdanyliv regarding @jods4 comment - do you remember what drived you to create this feature?

[MaceWindu]

/azp run test-all

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[linq2dbot]

Test baselines changed by this PR. Don't forget to merge/close baselines PR after this pr merged/closed.

[viceroypenguin]

I agree with @jods4 - I'm not sure I like this being handled implicitly in the core library. If it's possible for this to be distributed as a related package, that would make sense. Maybe this can wait for #4401, in order to be done as a parallel package with the main l2db?

[MaceWindu]

That's not in core library but in linq2db.Tools

[jods4]

@MaceWindu missed that!
I still think it might not be the most maintainable approach (as Tools are an all-or-nothing deal) but at least it's separated from core.

[igor-tkachev]

We do not need to add any dependencies to linq2db project. If you do not like it, we can move it to linq2db.Tools, add dependency and move it to Examples, or delete it at all.

[jogibear9988]

If we add mapping for all properties of a nodadatetime object like Hour, Minute, ... as we do for DateTime and DateTimeOffset i think it is usefull to have such a extension (maybe in a Linq2Db.NodaDateTime assembly). But for this we need a extension like in #4401
So someone could use a NodaDateTime Object (don't know wich ones there exist) everywhere in a Linq query same as a DateTime could be used.

[viceroypenguin]

I'm good with being in linq2db.Tools, though I think a dedicated linq2db.NodaTime would be better, because it could have a direct dependency on NodaTime, which would simplify the mapping code from having to build custom expressions.

Also, it looks like the current code only maps the LocalDateTime type. A proper nodatime handler should map OffsetDateTime as well, as well as possibly LocalDate and LocalTime.

[igor-tkachev]

@viceroypenguin, direct dependency is one of forms of dll hell, something we struggled with unsuccessfully in bltoolkit (previous version of linq2db).

[viceroypenguin]

@viceroypenguin, direct dependency is one of forms of dll hell, something we struggled with unsuccessfully in bltoolkit (previous version of linq2db).

Yes, I agree, at least in the main library.

However, a) doing it in a dedicated library for that support is usually less concerning, and b) dependency management is significantly better today than it was 10 years ago.

[MaceWindu]

Remaining tasks:

• other NodaType types support
• (optional) members mapping
• extension to option instead of mapping schema