Skip to content

NH-1752 - NHibernate Date type converts to NULL #698

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Sep 26, 2017

Conversation

fredericDelaporte
Copy link
Member

NH-1752 - NHibernate Date type converts to NULL

Occurs when date is lower than year 1753.

This behavior is removed. This behavior was handy when nullable types were lacking, and a test was still relying on this.

For testing the change with SqlServer, I have migrated all SqlClient driver to Sql2008Client.

</property>
<property name="connection.driver_class">
NHibernate.Driver.SqlClientDriver
</property>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our doc examples incite users to use an obsolete driver for SqlServer: I have purged unneeded parameters.

@@ -51,7 +51,7 @@ protected override string MappingsAssembly

await (s.GetAsync<Person>(1));//will execute some sql

var loggingEvent = spy.Events[0];
var loggingEvent = spy.GetWholeLog();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ngbrown, it seems you have forgotten to regen Async files.

Copy link
Contributor

@ngbrown ngbrown Sep 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean. I run the ShowBuildMenu option H, and no files change.

There's no documentation at https://github.com/maca88/AsyncGenerator, so what does it even do?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was getting an error in the nuget restore, and didn't see that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#699 if you want to make a separate merge for that.

Copy link
Member Author

@fredericDelaporte fredericDelaporte Sep 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Contributing have been completed about that. But you now know about it.

That is not a big change so I would not have required a new PR. I will see if Alexander will rather merge your PR first or just mine.

@fredericDelaporte fredericDelaporte force-pushed the NH-1752 branch 3 times, most recently from 80c4fb5 to 15575b4 Compare September 21, 2017 20:52
/// <summary>
/// The minimal date supported by this driver.
/// </summary>
DateTime MinDate { get; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about other drivers?

The datetime range for MySQL, Oracle is 1000-01-01 to 9999-12-31

For Postgres is 4713 BC to 294276 AD

Copy link
Member Author

@fredericDelaporte fredericDelaporte Sep 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just put .Net MinValue and let the test tell me if it was ok. So that is strange for MySql/Oracle. And for Postgres, as .Net native type does not allow BC dates, it is limited by .Net rather than by the DB, but that still means a limit at MinValue. Otherwise we could switch that property to nullable for meaning that the actual limit is below .Net own limit, but I do not think it is worth it.

Copy link
Member Author

@fredericDelaporte fredericDelaporte Sep 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this other doc, Oracle DATE support dates down to 4712 BC. So I think we can keep MinDate for Oracle.

About MySql, they also write:

For the DATE and DATETIME range descriptions, “supported” means that although earlier values might work, there is no guarantee.

So it just happens to work in our case, but we should not complain if it ceases too. I will set its MinDate accordingly.

{
var basic = new DateClass { DateValue = new DateTime(1899,1,1) };
var basic = new DateClass { DateValue = expected.AddHours(1) };
Copy link
Member

@hazzik hazzik Sep 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding one hour does not make sense here as we only store date. Ah, I got this test now. Stupid me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got screwed first too, I could have added a comment.

@@ -55,36 +56,30 @@ public void ReadWriteNormal()
{
var expected = DateTime.Today.Date;
Copy link
Member

@hazzik hazzik Sep 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not need to call .Date on .Today as it is already a bare date

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure I could have cleaned that, just had refactored previous code in a common method without changing the logic.

@hazzik
Copy link
Member

hazzik commented Sep 22, 2017

I don't understand how the tests work for MySQL and Oracle as their datetime range starts from year one thousand.

protected override bool AppliesTo(ISessionFactoryImplementor factory)
{
return factory.ConnectionProvider.Driver is Sql2008ClientDriver;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, this one is checked after schema creation. So if the schema cannot be created for the test, we have to test the driver by checking TestCase.Cfg property in the dialect AppliesTo, somewhat like here.

It is coded as if creating the factory was requiring the schema to be there.

Configure();
if (!AppliesTo(Dialect))
{
	Assert.Ignore(GetType() + " does not apply to " + Dialect);
}

CreateSchema();
try
{
	_sessionFactory = BuildSessionFactory();
	if (!AppliesTo(_sessionFactory))
	{
		Assert.Ignore(GetType() + " does not apply with the current session-factory configuration");
	}
}
catch
{
	DropSchema();
	throw;
}

We could rewrite it:

Configure();
if (!AppliesTo(Dialect))
{
	Assert.Ignore(GetType() + " does not apply to " + Dialect);
}

_sessionFactory = BuildSessionFactory();
if (!AppliesTo(_sessionFactory))
{
	Assert.Ignore(GetType() + " does not apply with the current session-factory configuration");
}
CreateSchema();

public void ReadWriteYear750()
{
var expected = new DateTime(750, 5, 13);
if (Sfi.ConnectionProvider.Driver.MinDate < expected)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be reversed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are correct

@fredericDelaporte
Copy link
Member Author

May we merge this? It may allow me to do more clean-up in ongoing #703.

hazzik
hazzik previously approved these changes Sep 25, 2017
@hazzik
Copy link
Member

hazzik commented Sep 25, 2017

Sure. Can you also rebase/squash it before merging?

It was inciting to put uneeded or even harmfull settings (forcing use of old sql client driver instead of 2008).
Obsolete base date parameterization and set its default value to MinDate
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants