NH-3919 - Clean up and harmonize datetime types with regards to different dialects #703

fredericDelaporte · 2017-09-24T17:00:36Z

NH-3919 - Clean up and harmonize datetime types with regards to different dialects.

Possible breaking changes:

NHibernate type DateTimeType, which is the default for a .Net DateTime, does no longer cut fractional seconds. Use DateTimeNoMsType if you wish to have fractional seconds cut. It applies to its Local/Utc counterparts too.
LocalDateTimeType and UtcDateTimeType do no more accept being set with value having a non-matching kind, they throw instead.
DbTimestamp will now round the retrieved value according to Dialect.TimestampResolutionInTicks.
When an object typed property is mapped to a NHibernate timestamp, setting an invalid object in the property will now throw at flush instead of replacing it with DateTime.Now.
SQL Server 2008+ dialects now use datetime2 instead of datetime for all date time types, including timestamp. This can be reverted with sql_types.keep_datetime setting.
SQL Server 2008+ timestamp resolution is now 100ns in accordance with datetime2 capabilities, down from 10ms previously. This can be reverted with sql_types.keep_datetime setting.
Oracle 9g+ dialects now use timestamp(7) for all date time types, instead of timestamp(4).
Oracle 9g+ timestamp resolution is now 100ns in accordance with timestamp(7) capabilities, down from 100µs previously.
String parameter length will no more be specified by the OdbcDriver.
IMapping interface has an additional Dialect member. ISessionFactoryImplementor has lost it, since it gains it back through IMapping.
IDriver.ExpandQueryParameters and DriverBase.CloneParameter take an additional argument.

fredericDelaporte · 2017-09-24T17:02:32Z

src/NHibernate.Test/NHSpecificTest/NH283/Fixture.cs

@@ -21,11 +21,11 @@ public void ForeignKeyNames()


 			string script = string.Join("\n",
-			                            cfg.GenerateSchemaCreationScript(new MsSql2000Dialect()));
+			                            cfg.GenerateSchemaCreationScript(new MsSql2008Dialect()));


SQL 2000 dialect was failing due to "unknow type datetime2"...

fredericDelaporte · 2017-09-24T17:03:31Z

src/NHibernate.Test/NHibernate.Test.csproj

@@ -1,26 +1,21 @@
 <Project Sdk="Microsoft.NET.Sdk">
  <Import Project="../../build-common/NHibernate.props" />
-


Should I revert those riders glitches, or just let it do that once and hopefully for all?

fredericDelaporte · 2017-09-24T17:07:50Z

src/NHibernate/Dialect/MsSql2008Dialect.cs

@@ -36,5 +74,26 @@ protected override void RegisterDefaultProperties()
 			base.RegisterDefaultProperties();
 			DefaultProperties[Environment.ConnectionDriver] = typeof(Sql2008ClientDriver).AssemblyQualifiedName;
 		}
+
+		public override string CurrentTimestampSQLFunctionName =>
+			"SYSDATETIME()";


Previously it was using CURRENT_TIMESTAMP, calling indeed getdate(), so yielding datetime instead of datetime2.

fredericDelaporte · 2017-09-24T17:10:25Z

src/NHibernate/Hql/Ast/ANTLR/Tree/IdentNode.cs

@@ -39,7 +39,7 @@ public override IType DataType
 					return fe.DataType;
 				}
 				ISQLFunction sf = Walker.SessionFactoryHelper.FindSQLFunction(Text);
-				return sf == null ? null : sf.ReturnType(null, null);
+				return sf?.ReturnType(null, Walker.SessionFactoryHelper.Factory);


Unique case I have spotted where a methods chain of calls ending by calling IType.SqlTypes was not supplying an IMapping (the factory in this case).

fredericDelaporte · 2017-09-24T17:12:25Z

src/NHibernate/Type/ClassMetaType.cs

@@ -16,7 +16,8 @@ public partial class ClassMetaType : AbstractType
 	{
 		public override SqlType[] SqlTypes(IMapping mapping)
 		{
-			return new SqlType[] { NHibernateUtil.String.SqlType };
+			var types = new[] { NHibernateUtil.String.SqlType };
+			return mapping?.Dialect.RefineSqlTypes(this, types) ?? types;


I have added that logic for each type, excepted those yielding no types and those building them from other types.

fredericDelaporte · 2017-09-24T17:22:19Z

src/NHibernate/Type/NullableType.cs

@@ -34,9 +34,9 @@ private IInternalLogger Log

 		/// <summary>
 		/// Initialize a new instance of the NullableType class using a 
-		/// <see cref="SqlType"/>. 
+		/// <see cref="NHibernate.SqlTypes.SqlType"/>. 


It was referencing the NullabeType.SqType property otherwise.

fredericDelaporte · 2017-09-24T17:28:40Z

src/NHibernate/Type/NullableType.cs

 		{
-			return new SqlType[] {SqlType};
+			var types = new[] { SqlType };
+			return mapping?.Dialect.RefineSqlTypes(this, types) ?? types;


That the main change for supporting the feature: this allow switching the NHibernate type default corresponding sql type for another.

Hibernate does not do that. They do not need. Java does not know DbType.DateTime and DbType.DateTime2, it only knows Types.TIMESTAMP. Hibernate just need to tell this one should be mapped to sql type datetime2 in SQL 2008 dialect.

They, actually, do something similar: https://github.com/hibernate/hibernate-orm/blob/9f2edb654dd55cee67d1b0445bdc0f6ae716f5e9/hibernate-core/src/main/java/org/hibernate/dialect/PostgreSQL81Dialect.java#L179

They call it on nullSafeGet/nullSafeSet/extract(no equivalent on our side)

Ok. It does not seems near to be ported currently, since it depends on their type descriptor which is not ported currently, and uses instance overrides for doBind which relies on members of the calling class, pattern not doable that way in .Net. (We could likely use method delegates instead.) And I have not checked if their override is taken into account also for hbm2ddl, as mine.

fredericDelaporte · 2017-09-24T17:36:18Z

src/NHibernate.Test/TypesTest/DateTimeTypeFixture.cs

+		{
+			var validator = new SchemaValidator(cfg);
+			validator.Validate();


Delegating to Validate for checking we have the expected type in database. Which means being confident Validate correctly knows if it should be DateTime or DateTime2.
It appeared to me overly complicated to test this manually for all dialects, so I delegated to Validate. I have furthermore checked in a debug session directly in the db what type it was to ascertain we were now having datetime2 with SQL2008.

fredericDelaporte · 2017-09-24T22:55:12Z

src/NHibernate.Test/TypesTest/DateTimeTypeFixture.cs

 		}

-		private void AssertSqlType(ClientDriverWithParamsStats driver)
+		private void AssertSqlType(ClientDriverWithParamsStats driver, int expectedCount)


Checking the exact usage count by the way.

fredericDelaporte · 2017-09-24T23:01:23Z

src/NHibernate.Test/TypesTest/DateTimeTypeFixture.cs

 		}

 		[Test]
 		public void QueryUseExpectedSqlType()
 		{
+			if (!TestDialect.SupportsNonDataBoundCondition)
+				Assert.Ignore("Dialect does not support the test query");


Debuging the failure, the expected DbType and SqlType usages count is found (5), but Firebird does not accept the last condition. Removing it allows the query to be executed, but I want this condition for avoiding having the Hql parser determining the type for all parameters from the properties they are compared to, and instead use the type supplied by the parameter. So I ignore this test for Firebird.

fredericDelaporte · 2017-09-25T18:34:29Z

Last commit is part 2. I intend to add more tests though.

fredericDelaporte · 2017-09-25T22:23:12Z

src/NHibernate.Test/Async/Operations/MergeFixture.cs

-			var grandchild = new Node {Name = "grandchild"};
+			var root = new Node
+			{
+				Created = RoundForDialect(DateTime.Now),


Just fixing the trouble in test. It could be fixed at the type level by overriding IsEqual (and preferably setter and getter too). But this would be a possible breaking change for timestamp when used a as simple property, because this will cause it to use the dialect declared accuracy instead of the actual database accuracy.

fredericDelaporte

Odbc causes issue with milliseconds due to NH-3895 which does not seem actually fixed when the Loader is used.

fredericDelaporte · 2017-09-26T00:54:53Z

src/NHibernate.Test/NHSpecificTest/NH3567/Mappings.hbm.xml

@@ -6,23 +6,23 @@
    <id name="Id" type="Int32">
      <generator class="assigned" />
    </id>
-    <property name="Name" length="2000" />
+    <property name="Name" length="1999" />


With below change to expand parameters, the size defined by OdbcDriver now actually ends in final parameters, and it causes issues for nvarchar(2000) and above: they get converted to NText by ODBC, causing:

ERROR [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]The data types nvarchar and ntext are incompatible in the equal to operator.

So here this is just a workaround for this test which was not about long string. But I fear there is a serious trouble with Odbc, and we should consider removing that size specification which was not actually taken into accont until below change.

I have searched about this trouble of ODBC switching to ntext for nvarchar >= 2000. Only to find someone confirming it here, but no one seem to have a clue about why is it like this.

fredericDelaporte · 2017-09-26T01:01:34Z

src/NHibernate/Driver/DriverBase.cs

@@ -231,7 +231,7 @@ public void RemoveUnusedCommandParameters(DbCommand cmd, SqlString sqlString)
 				.ForEach(unusedParameterName => cmd.Parameters.RemoveAt(unusedParameterName));
 		}

-		public virtual void ExpandQueryParameters(DbCommand cmd, SqlString sqlString)
+		public virtual void ExpandQueryParameters(DbCommand cmd, SqlString sqlString, SqlType[] parameterTypes)


This method in the case of ODBC was replacing the original parameters by new one, partially clone, leaving aside Scale, Precision and Size set by OdbcDriver.InitializeParamater. So I wonder if those changes in InitializeParameter were tested. It does not seem to be the case. When looking at NH-3895 which was supposed to be fixed by one of those changes, there are no test in the commit.

Due to ExpandQueryParameters, Scale is lost. Due to the change in DateTimeType, we now have milliseconds, and this has triggered the NH-3895 bug for numerous tests. So I have changed ExpandQueryParameters for it to create parameters the same way as original one, calling InitializeParamater. This fixes NH-3895. But it has triggered the trouble explained in previous comment.

Having dug into files history, the size setting has been added with 03eb58a in January 2010, while the ExpandQueryParameters was not yet there. This one has been added in July 2010 with 131b97e. So, not having Size/Precision/Scale actually specified for Odbc parameters (and all other drivers not handling named parameters - DB2, Ifx, Ingres, OleDb, OracelLite, SybaseAsa - if they do set them in InitializeParameter,) is an old regression.

But later on NH-3036 reverted the size setting for sql client due to issues with like (which may requires larger size than the actual column size)~~, so I think we should remove this Size setting from Odbc parameters too~~.
In fact Odbc seems to re-adjust size anyway according to some comment in Set of string type.

fredericDelaporte · 2017-09-26T01:04:18Z

src/NHibernate/AdoNet/Util/SqlStatementLogger.cs

-			//TODO: Fix me after 4.6.2 update. Size and Precision has been added to DbParameter
-			var p = dataParameter as IDbDataParameter;
-			if (p != null)
-				return p.DbType + " (" + p.Size + ":" + p.Scale + ":" + p.Precision + ")";


Have I missed something or this todo was wrong on the version number? Precision was added in 4.5.1, and others are older.

fredericDelaporte · 2017-09-26T13:59:10Z

src/NHibernate.Test/Legacy/CriteriaTest.cs

@@ -29,14 +29,14 @@ public void SimpleSelectTest()
 			long simple1Key = 15;
 			Simple simple1 = new Simple();
 			simple1.Address = "Street 12";
-			simple1.Date = DateTime.Now;
+			simple1.Date = RoundForDialect(DateTime.Now);


Many tests comparing date before and after saving are changed to round them to the dialect known accuracy. Previously they were rounded to seconds due to DateTimeType Hibernate like semantic. Now that NHibernate does no more round to second for this type, we need to take into account the database accuracy.

fredericDelaporte · 2017-09-26T14:02:07Z

src/NHibernate.Test/NHSpecificTest/NH3818/Fixture.cs

@@ -40,31 +38,33 @@ public void SelectConditionalValuesTest()
                        .Select(o => new
                        {
                            o.Color,
-                            AliveDays = (int)(DateTime.Now - o.Birthdate).TotalDays,
+                            AliveDays = (now - o.Birthdate).TotalDays,


Test had start being flaky with DateTimeType no more truncating to seconds. The diff followed by TotalDays does not count boundaries but a fractional days count. We should not truncate it to int but better instead compare with a tolerance.

fredericDelaporte · 2017-09-26T14:03:30Z

src/NHibernate.Test/TypesTest/DateTime2TypeFixture.cs

@@ -23,14 +24,14 @@ public void Next()
 		[Test]
 		public void Seed()
 		{
-			DateTimeType type = NHibernateUtil.DateTime;
+			var type = NHibernateUtil.DateTime2;


Yuck. Was not testing what it was supposed to.

fredericDelaporte · 2017-09-26T14:04:20Z

src/NHibernate.Test/TypesTest/DateTimeNoMsTypeFixture.cs

+	/// TestFixtures for the <see cref="DateTimeNoMsType"/>.
+	/// </summary>
+	[TestFixture]
+	public class DateTimeNoMsTypeFixture


In fact this is what was DateTimeTypeFixture.

fredericDelaporte · 2017-09-26T14:11:42Z

src/NHibernate.Test/TypesTest/StringTypeWithLengthFixture.cs

-			// This test fails against the ODBC driver. The driver would need to be override to allow longer parameter sizes than the column.
-			AssertExpectedFailureOrNoException(
-				exception,
-				(Sfi.ConnectionProvider.Driver is OdbcDriver));


Was no more failing since 131b97e which was losing the Size set on parameter. But since "expand parameter" is now fixed, it would fail again if we do not do NH-4083.

fredericDelaporte · 2017-09-26T14:45:20Z

src/NHibernate/Type/TimestampType.cs


 namespace NHibernate.Type
 {
 	/// <summary>
-	/// This is almost the exact same type as the DateTime except it can be used
-	/// in the version column, stores it to the accuracy the database supports, 
-	/// and will default to the value of DateTime.Now if the value is null.


default to the value of DateTime.Now if the value is null: wrong, since it was "implemented" into Set which is not called when the value is null.
Moreover since when this comment was written, it seems DateTimeType has gained the ability to serve as version too.

fredericDelaporte · 2017-09-26T14:47:53Z

src/NHibernate/Type/TimestampType.cs

-	/// and will default to the value of DateTime.Now if the value is null.
+	/// This is almost the exact same type as the <see cref="DateTimeType" /> excepted it can be used
+	/// in the version column, stores it to the accuracy the database supports
+	/// and will default to the value of <see cref="TimestampType.Now" /> if the value is not valid.


We may remove that since I do not think it was intended, the aim for the code being to replace null values, but in a method which is never called on null. It coud be a breaking change for edge cases, where a timestamp is mapped to an object property in which the app may put non DateTime data...

I have left the accuracy part in case for some reason we were to reduce DateTimeType one again.

fredericDelaporte · 2017-09-26T14:50:42Z

src/NHibernate/Type/TimestampType.cs

-		}
+		/// <inheritdoc />
+		protected override DateTime GetDateTimeToSet(object value, ISessionImplementor session) =>
+			(value as DateTime?) ?? Now;


This override should be removed if we want to clean the failed attempt at replacing null values by Now. By the way if keeping it, we should probably call Seed instead of Now.

fredericDelaporte · 2017-09-26T14:54:54Z

src/NHibernate/Type/TimestampType.cs

-			return '\'' + value.ToString() + '\'';
-		}
+		public override string ToString(object val) =>
+			((DateTime) val).ToString("O");


Maybe the only significant change of Timestamp compared to the new DateTimeType.

fredericDelaporte · 2017-09-26T14:58:53Z

src/NHibernate/Type/TimestampUtcType.cs

+			var dbValue = base.GetDateTimeToSet(value, session);
+			if (dbValue.Kind != DateTimeKind.Utc)
+				throw new ArgumentException("Kind is NOT Utc", nameof(value));
+			return dbValue;


With Timestamp.ToString, that is all the differences with UtcDateTimeType. UtcDateTimeType does not throw if it receives a non UTC value: it silently switch its kind to UTC.

fredericDelaporte · 2017-09-26T20:46:47Z

src/NHibernate/Cfg/Environment.cs

+		/// for dialects supporting datetime2.
+		/// </summary>
+		[Obsolete("Migrate SQL datetime type to datetime2 instead.")]
+		public const string SqlTypesKeepDateTime = "sql_types.keep_datetime";


DateTime2 being unsupported by OdbcDriver, we may use it for allowing using 2008 dialect with Odbc. So I think I will remove the obsolete attribute.

The subject is a bit deeper since Odbc does not understand Time either, and likely Date too: we should have a mean to switch those types too. So we can also decide that only dialects up to 2005 are compatible with ODBC.
(By the way this page states ODBC does support SQL2008 types, but how are we supposed to do in a .Net context, mystery.)

An other option would be to try moving the type override from dialect to driver. But currently IMapping interface which is where I pull the dialect from for refining types is not much suitable for having the driver, unless we add the ability for Configuration.Mapping to instantiate a driver.

I think I will just remove the Obsolete attribute.

fredericDelaporte · 2017-09-27T18:33:19Z

All date time types are now tested. One more bug to fix by the way.
I intend to test what it gives using timestamp as version on a SQL Server db having datetime columns instead of datetime2: it will surely cause stale update exceptions, which will be the main breaking change for this switch from datetime to datetime2.

hazzik · 2017-09-27T20:32:47Z

Such a Pandora's box.

fredericDelaporte · 2017-09-27T22:23:37Z

If it is not 5.0 it should be 6, too much changes for a minor.

hazzik · 2017-09-27T22:37:45Z

If it is not 5.0 it should be 6, too much changes for a minor.

I think this is better to leave it for 6. A good exercise for a types refactoring. At least much better than trying to rush in 5.0

* NHibernate date time types (datetime, timestamp, localdatetime, utcdatetime, dbtimestamp) use db type datetime2 if dialect supports it. * NHibernate type datetime2 is obsolete. * Add test for NH-3984 by Ralf Kornelius

* NHibernate DateTime type does not cuts milliseconds anymore * Add new types which cut milliseconds * Refactor everything together

fredericDelaporte · 2017-10-04T09:54:48Z

src/NHibernate/Dialect/TypeNames.cs

+				case DbType.Time:
+					return true;
+			}
+			return false;


Right, I have been a bit quick with the "refactor extract method here".

hazzik · 2017-10-04T21:10:18Z

I just realized that "NoMs" types are not needed anymore.

fredericDelaporte · 2017-10-05T10:34:58Z

Why, because we have scale? Scale is not understood and handled by every database.

fredericDelaporte force-pushed the NH-3919 branch from fcd9da3 to 67f96e7 Compare September 24, 2017 17:20

fredericDelaporte commented Sep 24, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-3919 branch from 67f96e7 to f9cfbac Compare September 24, 2017 17:54

fredericDelaporte commented Sep 24, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-3919 branch 2 times, most recently from a64b86d to 4572948 Compare September 25, 2017 09:12

fredericDelaporte mentioned this pull request Sep 25, 2017

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

Merged

fredericDelaporte commented Sep 25, 2017

View reviewed changes

fredericDelaporte commented Sep 26, 2017

View reviewed changes

fredericDelaporte added t: Bug t: Improvement labels Sep 26, 2017

fredericDelaporte added this to the 5.0 milestone Sep 26, 2017

fredericDelaporte force-pushed the NH-3919 branch 3 times, most recently from c859197 to fe35045 Compare September 26, 2017 14:38

fredericDelaporte commented Sep 26, 2017

View reviewed changes

fredericDelaporte mentioned this pull request Sep 26, 2017

NH-3884 - Default DateTime type can not be overridden #702

Merged

fredericDelaporte commented Sep 26, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-3919 branch 2 times, most recently from 509b41d to ee12f78 Compare September 27, 2017 18:31

fredericDelaporte force-pushed the NH-3919 branch from ee12f78 to 03879e2 Compare September 27, 2017 18:35

hazzik modified the milestones: 5.0, 5.1 Sep 27, 2017

hazzik previously approved these changes Oct 4, 2017

View reviewed changes

fredericDelaporte added 11 commits October 4, 2017 21:57

NH-3919 - Use DateTime2 for dialects supporting it.

1464f48

* NHibernate date time types (datetime, timestamp, localdatetime, utcdatetime, dbtimestamp) use db type datetime2 if dialect supports it. * NHibernate type datetime2 is obsolete. * Add test for NH-3984 by Ralf Kornelius

NH-3919 - Cease cutting milliseconds.

472bad0

* NHibernate DateTime type does not cuts milliseconds anymore * Add new types which cut milliseconds * Refactor everything together

NH-3895 - Fix expand parameters too.

612ea36

NH-3431 - Remove IDbDataParameter too.

2ee84a7

NH-4083 - Cease specifying parameter length for ODBC string

3be6668

NH-3919 - More datetime tests and refactor them.

72aaccb

NH-3919 - Obsolete TimestampType, check DateTime Kind

7ac0206

NH-4084 - DbTimeStamp cause stale update exception

a15a1a5

NH-3919 - Document changes in date time types.

d7b30a5

NH-3919 - Handle date and time scale.

a83bcb2

NH-4086 - TimeType may lose fractional seconds.

55ebc64

hazzik dismissed their stale review via 55ebc64 October 4, 2017 08:59

hazzik force-pushed the NH-3919 branch from 61d1752 to 55ebc64 Compare October 4, 2017 08:59

hazzik approved these changes Oct 4, 2017

View reviewed changes

fredericDelaporte commented Oct 4, 2017

View reviewed changes

fredericDelaporte merged commit c7845d8 into nhibernate:master Oct 4, 2017

fredericDelaporte deleted the NH-3919 branch October 4, 2017 13:56

fredericDelaporte added the r: Fixed label Oct 4, 2017

hazzik added a commit that referenced this pull request Oct 9, 2017

Set prepare_sql = true to test #703 changes

f164461

fredericDelaporte pushed a commit that referenced this pull request Oct 9, 2017

Set prepare_sql = true to test #703 changes

bfe2925

This was referenced Dec 7, 2017

Driver/DriverBase: When cloning a parameter, also copy size/scale/pre… #528

Closed

NH-4065 - MsSql Dialect + ODBC, mapping an nvarchar(max) using string(10000) causes string truncation #1360

Closed

fredericDelaporte mentioned this pull request Jul 20, 2018

NH-3984 - Improve type autodiscovery for datetime2 column in CreateSQLQuery() (CustomLoader) #772

Closed

fredericDelaporte mentioned this pull request Sep 16, 2018

Adjust string parameter sizes for MSSQL #1844

Merged

fredericDelaporte mentioned this pull request Dec 28, 2018

Caching of Property Dialect in class Configuration.Mapping #1950

Closed

fredericDelaporte mentioned this pull request Oct 16, 2020

sql_types.keep_datetime Reduces Precision of DateTimeOffset #2584

Closed

hazzik mentioned this pull request Aug 6, 2023

GenerateSchemaCreationScript creates many identical dialect instances #3397

Closed

		@@ -1,26 +1,21 @@
		<Project Sdk="Microsoft.NET.Sdk">
		<Import Project="../../build-common/NHibernate.props" />

NH-3919 - Clean up and harmonize datetime types with regards to different dialects #703

NH-3919 - Clean up and harmonize datetime types with regards to different dialects #703

Uh oh!

Conversation

fredericDelaporte commented Sep 24, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fredericDelaporte Sep 24, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 24, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte commented Sep 25, 2017

Uh oh!

fredericDelaporte Sep 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

fredericDelaporte commented Sep 24, 2017 •

edited

Loading

fredericDelaporte Sep 24, 2017 •

edited

Loading

fredericDelaporte Sep 24, 2017 •

edited

Loading

fredericDelaporte Sep 25, 2017 •

edited

Loading

fredericDelaporte left a comment •

edited

Loading

fredericDelaporte Sep 26, 2017 •

edited

Loading

fredericDelaporte Sep 26, 2017 •

edited

Loading

fredericDelaporte Sep 26, 2017 •

edited

Loading

fredericDelaporte Sep 26, 2017 •

edited

Loading