NH-2319 - Add ability to query collections with AsQueryable() #375

hazzik · 2014-11-19T20:30:39Z

No description provided.

fredericDelaporte

Is there a reason for not including idbags (PersistentIdentifierBag) and lists (PersistentGenericList) in the feature? Reading now the Jira, is this PR still limited to bidi one-to-many bag and set?

A bit like Fabio, I am not much convinced by the feature. It is nice to avoid loading the full collection in some cases, but well, this can easily be achieved with a query instead. Of course it is less straight forward, but since the feature seems currently so limited, it still looks as the default way to go for me.

Otherwise, I think we need an obvious mean for knowing we are in a currently unsupported case: throw an exception instead of falling back on linq-to-object? This has the advantage of being obvious for the developer. While the fallback to linq-to-object triggers silently the full load of the collection (and I guess from batch-size others too) and may be unnoticed by the developer. But if anyone has put some pointless AsQueryable() in its current code, it will be a breaking change. Maybe add a configuration property for choosing between fallback or throw.

For supporting maps, we would have to provide a dictionary with a custom Values implementation. Maybe not worth the trouble.

My review is just preliminary, I have not thoroughly studied (and understood) how this new feature works.

fredericDelaporte · 2017-04-11T17:36:59Z

src/NHibernate/Collection/Generic/PersistentGenericBag.cs

@@ -46,6 +49,8 @@ public class PersistentGenericBag<T> : AbstractPersistentCollection, IList<T>, I
 		 */
 		private IList<T> _gbag;

+		private IQueryable<T> queryable;


I tend to use _ underscore prefix for private fields, and changes fields which does not have it when I have already change a lot in the class. I see that these new queryable fields do not have it. Are we accepting both, or shall we use a single style, and which one?

I think this field needs the [NonSerialized] attribute.

It's a hundreds years old PR, so I don't remember/know why I didn't put underscore in front of the field name.

Agreed on [NonSerialized] part.

fredericDelaporte · 2017-04-11T17:47:34Z

src/NHibernate/Collection/Generic/PersistentGenericBag.cs

+
+		private IQueryable<T> InnerQueryable
+		{
+			get { return queryable ?? (queryable = new NhQueryable<T>(Session, this)); }


Isn't that the job of a new Lazy<NhQueryable<T>>(() => new NhQueryable<T>(Session, this)) which would be affected to a retyped queryable in the constructor?

I know we do not need thread safety here. This is just for avoiding coding this additional property and having a field which can be null if a later coder access it instead of using InnerQueryable.

Of course, we would then have to replace InnerQueryable calls by queryable.Value.

Other consideration: I think the field must be marked as non serializable. Better having them lazily recreated after deserialization. (The current pattern better support it. With a Lazy, we would need to implement ISerializable to recreate it I fear.)

Lazy<> is not really required. What's required is a proper implementation of IQueryable<>, and it turns out that NhQueryable<> is doing almost everything what we need.

fredericDelaporte · 2017-04-11T17:51:53Z

src/NHibernate/Collection/Generic/PersistentGenericSet.cs

@@ -38,6 +40,8 @@ public class PersistentGenericSet<T> : AbstractPersistentCollection, ISet<T>
 		[NonSerialized]
 		private IList<T> _tempList;

+		private IQueryable<T> queryable;
+


Same remarks as for previous class.

fredericDelaporte · 2017-04-11T18:23:21Z

src/NHibernate/Engine/Query/QueryPlanCache.cs


 			if (plan == null)
 			{
 				if (log.IsDebugEnabled)
 				{
-					log.Debug("unable to locate collection-filter query plan in cache; generating (" + collectionRole + " : "
-							  + filterString + ")");
+					log.Debug(string.Format("unable to locate collection-filter query plan in cache; generating ({0} : {1})", collectionRole, queryExpression.Key));


I guess at the time of this change, $"" formatting was not available!

I am frequently a bit surprised by those if (log.IsDebugEnabled): they are pointless if they are just about avoiding formatting without any value evaluation, aren't they? log.DebugFormat("", args) already handle that.

I guess at the time of this change, $"" formatting was not available!

True. However, It seems that it shall be changed to log.DebugFormat(..)

if (log.IsDebugEnabled)

It seems just to avoid doing string concatenations and win some milliseconds and object allocations (in some cases it's actually a huge win)

Haven't found anything on C#, so the links are about Java, but internals are almost the same, so

http://stackoverflow.com/questions/963492/in-log4j-does-checking-isdebugenabled-before-logging-improve-performance

https://www.igorkromin.net/index.php/2015/05/12/are-guard-statements-like-isdebugenabled-necessary-when-using-log4j/

http://learnertobeginner.blogspot.co.nz/2010/06/how-to-use-isdebugenabled-effectly.html

I am used to rarely need the explicit check, because I am mostly using Format suffixed methods when having to format a log. Of course sometime we need to format with computed values, or to have a more complex message construction. Then I use the explicit check. I am sensible to this because log messages are almost bloat code in my view, and I rather keep them as compact as possible. (Actually I tend to only log exceptions. I fully agree with Jeff Atwood blog on this.)

fredericDelaporte · 2017-04-11T18:34:55Z

src/NHibernate/Hql/Ast/ANTLR/HqlSqlWalker.cs

-
+
+			if (fromElementFound)
+				return (IASTNode) adaptor.Nil();


Has this been done because some of the calls above would have side effects? If yes, maybe a comment would be welcome. Otherwise I would tend to move this return in the if (fromElement == null) clause.

As I understand after a quick look-around. There are some differences in the AST between HQL and LINQ. It seems that LINQ AST already contains fromElement in the tree, and HQL does not.

We still need to do all these manipulations with the fromElement, but we do not want to add it back to the tree (because it is already there).

fredericDelaporte · 2017-04-11T18:39:05Z

src/NHibernate/Impl/SessionImpl.cs

+				CheckAndUpdateSessionStatus();
+				queryParameters.ValidateParameters();
+				var plan = GetFilterQueryPlan(collection, queryExpression, queryParameters, false);
+


Almost dup code here. I think this need to be refactored with above method.

fredericDelaporte · 2017-04-11T18:44:44Z

src/NHibernate/Impl/SessionImpl.cs

+			}
+		}
+
+		private IQueryExpressionPlan GetFilterQueryPlan(object collection, string filter, QueryParameters parameters, bool shallow)


Same here, lot of dup code with above method, should probably be refactored.

fredericDelaporte · 2017-04-11T18:48:08Z

src/NHibernate/Linq/NhQueryable.cs

@@ -46,11 +46,17 @@ public NhQueryable(IQueryProvider provider, Expression expression, string entity
 			EntityName = entityName;
 		}

+		public NhQueryable(ISessionImplementor session, object collection)
+			: base(new DefaultQueryProvider(session, collection))


Shouldn't it use the QueryProviderFactory?

Yes. But it wasn't here when this code was written.

hazzik · 2017-04-24T05:06:01Z

Is there a reason for not including idbags (PersistentIdentifierBag) and lists (PersistentGenericList) in the feature?

It's because this feature is really just a strongly-typed wrapper on a filter collection feature which does not support these collections

hazzik · 2017-04-24T05:43:00Z

Also, Hibernate is moving towards this direction as well.

They are going to:

deprecate session#createFilter in HHH-11390
shift support for "collection filtering" to Java 8 Streams (a java version of LINQ) in HHH-10962

hazzik · 2017-04-24T06:18:17Z

About the differences in LINQ vs HQL:

Linq generates following AST:

( query ( select_from ( from ( range NHibernate.Test.NHSpecificTest.NH2319.Child x ) ) ( select x ) ) ( where ( == ( . x Name ) ( : p1 ) ) ) )

And HQL:

"( query ( SELECT_FROM {filter-implied FROM} ) ( where ( = ( . this Name ) 'Jack' ) ) )"

So, it's better to eliminate the initial difference in the AST tree instead of modifying CreateFromFilterElement

fredericDelaporte · 2017-04-24T18:50:10Z

I never needed to use filters so I am not sure, but are filter supporting batch loading of collection? I tend to think yes, and then, deprecating filters for queryable collections may cause a significant performances loss, unless we find a way to maintain batching with queryable collections.

fredericDelaporte · 2017-04-24T19:00:20Z

Hibernate team seems to want to only remove the special query on collection case. I was thinking about the more global filters functionality, declarable in mappings. Well, I never found this query on collection feature very useful, it is so easy to just write a usual query doing the same job.

hazzik · 2017-04-24T19:53:52Z

Hibernate team seems to want to only remove the special query on collection case.

Yes, only this Session#createFilter feature. They want to replace HQL version with Java Streams API.

global filters functionality, declarable in mappings

Not these filters:) I know it confusing to have 2 distinct features share similar names

Well, I neither find this query on collection feature very useful, it is so easy to just write a usual query doing the same job.

Actually, [some] people are desperate to have this feature implemented. It's one of the highest voted features in the JIRA.

hazzik · 2017-04-25T22:26:56Z

Later SELECT_FROM {filter-implied FROM} is replaced by HqlFilterPreprocessor with SELECT_FROM ( FROM NHibernate.DomainModel.Many this ) which makes the queries identical except the alias name (this for HQL, and whatever for LINQ)

fredericDelaporte · 2017-09-09T00:10:15Z

Rebased. Once rebased some tests were failing when run in sequence with others, due to a trouble when a filtered query plan was retrieved from cache.
And refactored.

fredericDelaporte

Some monthes ago I had not checked the Jira proposed implementation.
Appearing more simple, it has probably way more limitations and shortcomings than the one you have made.

Maybe we should add more tests for checking that your implementation support all non bidi cases, perhaps many-to-many too, ... All cases supported by the filter feature should be supported, but I do not know much what it does support in fact.

I forgot to regen async for all commits, going to do that too.

Edit: just realized idBag were many-to-many. So it just lacking testing other unidi cases and maybe bidi with inverse.

fredericDelaporte · 2017-09-09T00:11:44Z

src/NHibernate/Collection/AbstractPersistentCollection.cs

@@ -79,7 +79,7 @@ public void Reset()
 				}
 			}
 		}
-
+		


Cleanup glitch, going to fix and repush forced.

fredericDelaporte · 2017-09-09T00:16:05Z

src/NHibernate/Impl/SessionImpl.cs

+				role => Factory.QueryPlanCache.GetFilterQueryPlan(filter, role, shallow, EnabledFilters));
+		}
+
+		private IQueryExpressionPlan GetFilterQueryPlan(object collection, QueryParameters parameters, Func<string, IQueryExpressionPlan> getPlanForRole)


I usually avoid this kind of pattern, putting code in common thanks to function pointers passed around. But here, with the function being defined for all cases right above, I think it is ok.

Does not seem compatible with Async generator, causes the removal of GetFilterQueryPlanAsync. ~~Now I wonder what IO are there in that function, going to check.~~ Ok it flushes, already forgot...

fredericDelaporte · 2017-09-09T00:16:56Z

src/NHibernate/Linq/QueryProviderFactory.cs

+				// For backward compatibility, prioritize using the version without collection.
+				return (collection == null
+					? Activator.CreateInstance(session.Factory.Settings.LinqQueryProviderType, session)
+					: Activator.CreateInstance(session.Factory.Settings.LinqQueryProviderType, session, collection)) as INhQueryProvider;


Minimal backward compatibility handling.

fredericDelaporte · 2017-09-09T01:07:54Z

src/NHibernate/Impl/SessionImpl.cs

+				if (filter != null && queryExpression != null)
+					throw new ArgumentException($"Either {nameof(filter)} or {nameof(queryExpression)} must be specified, not both.");
+				if (filter == null && queryExpression == null)
+					throw new ArgumentException($"{nameof(filter)} and {nameof(queryExpression)} were both null.");


I do not like this kind of parameter semantic but do not see a better solution for avoiding code duplication and not using a pattern not handled by async generator.

fredericDelaporte · 2017-09-09T09:17:32Z

src/NHibernate.Test/NHSpecificTest/Logs/LogsFixture.cs

@@ -73,6 +74,7 @@ public TextLogSpy(string loggerName, string pattern)
 				};
 				loggerImpl = (Logger)LogManager.GetLogger(typeof(LogsFixture).Assembly, loggerName).Logger;
 				loggerImpl.AddAppender(appender);
+				previousLevel = loggerImpl.Level;
 				loggerImpl.Level = Level.All;


This spy was used only for NHibernate.SQL, but that is an heavily logging logger. Better restore its previous log level.

fredericDelaporte · 2017-09-09T09:18:25Z

src/NHibernate.Test/SystemTransactions/ResourceManagerFixture.cs

@@ -684,7 +684,6 @@ void Clone_TransactionCompleted(object sender, TransactionEventArgs e)
 		[OneTimeSetUp]
 		public void TestFixtureSetUp()
 		{
-			((Logger)_log.Logger).Level = log4net.Core.Level.Info;
 			_spy = new LogSpy(_log);


Undue log level manual change, since LogSpy set it to Debug anyway.

fredericDelaporte · 2017-09-09T19:39:36Z

doc/reference/modules/query_linq.xml

+    <para>
+      If the collection is a map, call <literal>AsQueryable</literal> on its <literal>Values</literal>
+      property.
+    </para>


Added support for map.

fredericDelaporte · 2017-09-09T19:39:43Z

src/NHibernate.Test/NHSpecificTest/NH1612/NativeSqlCollectionLoaderFixture.cs

-			Assert.That((ICollection) country.Statistics.Keys, Is.EquivalentTo((ICollection) stats.Keys), "Keys");
-			Assert.That((ICollection) country.Statistics.Values, Is.EquivalentTo((ICollection) stats.Values), "Elements");
+			Assert.That(country.Statistics.Keys, Is.EquivalentTo(stats.Keys), "Keys");
+			Assert.That(country.Statistics.Values, Is.EquivalentTo(stats.Values), "Elements");


Those casts were likely required for an older NUnit. Since I have not additionally implemented ICollection on the map values wrapper, they were failing. We will probably have to document that as a possible breaking change.

fredericDelaporte · 2017-09-09T19:41:35Z

src/NHibernate.Test/NHSpecificTest/NH2319/MapFixture.cs

+				var filtered = parent.ChildrenMap.Values
+					.AsQueryable()
+					.Where(x => x.Name == "Piter")
+					.SelectMany(x => x.GrandChildren)


Not a map here. Supporting maps inside lambda would be another feature. (Currently already doable by pretending the map is a ICollection<TValue> with a cast, but a bit hackish.)

fredericDelaporte · 2017-09-09T19:43:23Z

src/NHibernate.Test/NHSpecificTest/NH2319/MapFixture.cs

+				rc.Id(x => x.Id, m => m.Generator(Generators.GuidComb));
+				rc.Property(x => x.Name);
+				rc.Map(x => x.ChildrenMap,
+					map => map.Cascade(Mapping.ByCode.Cascade.All | Mapping.ByCode.Cascade.DeleteOrphans),


I have not found how to specify the index, although we can specify it in hbm. Missing feature of by code mapping? Anyway, works with defaults for the test.

It is supposed that you use the Map overload which takes 4 lambdas, but IMapKeyRelation is missing the index part.

Or probably Element will behave as you need.

fredericDelaporte · 2017-09-09T19:44:30Z

src/NHibernate.Test/NHibernate.Test.csproj

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


Hum, probable Rider glitch... Bad point for that IDE.

fredericDelaporte · 2017-09-09T19:46:48Z

src/NHibernate/Collection/Generic/PersistentGenericMap.cs

+
+			public ValuesWrapper(PersistentGenericMap<TKey, TValue> map)
+			{
+				_map = map;


Just storing the persistent map, not the values, since the underlying map may still be changed at that point.

fredericDelaporte · 2017-09-09T19:49:03Z

src/NHibernate/Collection/Generic/PersistentGenericMap.cs

@@ -22,15 +25,22 @@ namespace NHibernate.Collection.Generic
 	[DebuggerTypeProxy(typeof(DictionaryProxy<,>))]
 	public partial class PersistentGenericMap<TKey, TValue> : AbstractPersistentCollection, IDictionary<TKey, TValue>, ICollection
 	{
-		protected IDictionary<TKey, TValue> WrappedMap;
+		protected IDictionary<TKey, TValue> WrappedMap { get; private set; }


Protected only for one test file, looks like it should have been private but experienced a probable "rogue" change. At least switched to property with private setter.

Can this please be reverted? And the test needs to change to use .Entries(...) method instead.

fredericDelaporte · 2017-09-09T19:51:10Z

src/NHibernate/Collection/Generic/PersistentGenericMap.cs

-		public PersistentGenericMap() { }
+		public PersistentGenericMap()
+		{
+			_wrappedValues = new ValuesWrapper(this);


x3, one for each constructor: they cannot call each over and the field cannot be initialized in place when using this.

fredericDelaporte · 2017-09-09T19:52:53Z

src/NHibernate/Collection/Generic/PersistentGenericMap.cs

@@ -347,8 +358,7 @@ public ICollection<TValue> Values
 		{
 			get
 			{
-				Read();
-				return WrappedMap.Values;
+				return _wrappedValues;


Read() moved to ValuesWrapper ICollection<TValue> members. Otherwise, reaching Values for calling AsQueryable was loading the map.

fredericDelaporte · 2017-09-09T19:59:02Z

I will not merge it myself since it would be a bit auto-approval of my own non cosmetic changes.

fredericDelaporte

Reverted changes to test csproj.

Especially one rogue change causing all subsequent test to have NHibernate.SQL logger enabled.

fredericDelaporte

(Just rebased.)

hazzik · 2017-09-12T02:40:30Z

src/NHibernate/Collection/Generic/PersistentGenericMap.cs

+				return GetEnumerator();
+			}
+
+			public void Add(TValue item)


Dictionary's "Values" collection is read-only.

Must still implement the interface, and I am just letting the throw be done by the underlying collection. But just for doing that, it triggers the read. Would you rather have a direct throw not reading at all? Since it is an error case anyway, I do not tend to optimize it.

I don't think this actually matters much, so let it be this way.

It does not matter much but I have already changed it anyway, just not yet pushed.

But how about "I do not tend to optimize it."?

fredericDelaporte

Requested changes done.

hazzik

LGTM

fredericDelaporte

I dislike keeping a non private field naming on such a member, but well, if you prefer minimize changed lines count...

hazzik added this to the 5.0.0 milestone Nov 19, 2014

hazzik force-pushed the NH-2319 branch from 87fb4e7 to 901f468 Compare November 19, 2014 20:38

hazzik added the investigate label Feb 24, 2015

hazzik force-pushed the master branch from e20411b to 9b7a5a3 Compare October 26, 2016 01:26

hazzik changed the base branch from master to 5.0.x November 28, 2016 21:45

oskarb closed this Nov 28, 2016

hazzik changed the base branch from 5.0.x to master November 29, 2016 00:02

hazzik reopened this Nov 29, 2016

hazzik requested a review from fredericDelaporte April 11, 2017 11:07

hazzik force-pushed the NH-2319 branch from 901f468 to 74f9bb0 Compare April 11, 2017 11:35

fredericDelaporte reviewed Apr 11, 2017

View reviewed changes

hazzik force-pushed the NH-2319 branch from 20b6f49 to 28af194 Compare April 25, 2017 23:55

hazzik added t: New Feature and removed investigate labels Aug 6, 2017

hazzik force-pushed the NH-2319 branch from 399598f to c9975fb Compare August 6, 2017 23:31

fredericDelaporte force-pushed the NH-2319 branch from c9975fb to cb1930e Compare September 9, 2017 00:09

fredericDelaporte reviewed Sep 9, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-2319 branch from cb1930e to 9ac4f3c Compare September 9, 2017 01:04

fredericDelaporte reviewed Sep 9, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-2319 branch from 0c48f88 to 642979f Compare September 9, 2017 09:12

fredericDelaporte reviewed Sep 9, 2017

View reviewed changes

fredericDelaporte force-pushed the NH-2319 branch from 642979f to b61a5a9 Compare September 9, 2017 09:58

fredericDelaporte force-pushed the NH-2319 branch from 92f3859 to 36f5cb1 Compare September 9, 2017 19:26

fredericDelaporte previously approved these changes Sep 9, 2017

View reviewed changes

fredericDelaporte dismissed their stale review via 79f34ed September 11, 2017 10:32

fredericDelaporte force-pushed the NH-2319 branch from 36f5cb1 to 79f34ed Compare September 11, 2017 10:32

fredericDelaporte previously approved these changes Sep 11, 2017

View reviewed changes

hazzik and others added 8 commits September 11, 2017 18:28

NH-2319 - Add ability to query collections with AsQueryable()

96ef51c

NH-2319 - Fix plan retrieved from cache case. To be squashed.

f8ba920

NH-2319 - Refactoring to be squashed.

7f07d1a

NH-2319 - documenting the feature, to be squashed.

d37b6e6

NH-2319 - Test case dedicated to plan cache previous bug, to be squashed

6751fb0

Cleanup log level handling.

24c8cfc

Especially one rogue change causing all subsequent test to have NHibernate.SQL logger enabled.

NH-2319 - Testing major mapping cases, to be squashed.

e937d0f

NH-2319 - AsQueryable Map support, to be squashed.

ac0275b

fredericDelaporte dismissed their stale review via ac0275b September 11, 2017 16:28

fredericDelaporte force-pushed the NH-2319 branch from 28a4cb8 to ac0275b Compare September 11, 2017 16:28

fredericDelaporte previously approved these changes Sep 11, 2017

View reviewed changes

hazzik commented Sep 12, 2017

View reviewed changes

NH-2319 - AsQueryable Map support adjustments, to be squashed.

6cdf008

fredericDelaporte dismissed their stale review via 6cdf008 September 12, 2017 11:58

fredericDelaporte previously approved these changes Sep 12, 2017

View reviewed changes

hazzik commented Sep 12, 2017

View reviewed changes

hazzik dismissed fredericDelaporte’s stale review via 422e60e September 12, 2017 22:49

NH-2319 - AsQueryable Map support adjustments, to be squashed.

fd7fb0c

hazzik force-pushed the NH-2319 branch from 422e60e to fd7fb0c Compare September 12, 2017 22:50

fredericDelaporte approved these changes Sep 13, 2017

View reviewed changes

fredericDelaporte merged commit 2e20261 into nhibernate:master Sep 13, 2017

fredericDelaporte added the r: Fixed label Sep 13, 2017

hazzik deleted the NH-2319 branch September 29, 2017 23:12

fredericDelaporte mentioned this pull request Aug 16, 2020

AsQueryable() on collection throws if applied after Where statement #2471

Closed

@@ @@ -79,7 +79,7 @@ public void Reset() @@
               				}
               			}
               		}

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

NH-2319 - Add ability to query collections with AsQueryable() #375

NH-2319 - Add ability to query collections with AsQueryable() #375

Uh oh!

Conversation

hazzik commented Nov 19, 2014

Uh oh!

fredericDelaporte left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hazzik Apr 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!

fredericDelaporte Apr 11, 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!

hazzik Apr 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!

hazzik Apr 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!

hazzik commented Apr 24, 2017

Uh oh!

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

Uh oh!

Uh oh!

hazzik commented Apr 24, 2017

Uh oh!

fredericDelaporte commented Apr 24, 2017

Uh oh!

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

Uh oh!

Uh oh!

hazzik commented Apr 24, 2017

Uh oh!

hazzik commented Apr 25, 2017

Uh oh!

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

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Sep 9, 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!

hazzik Apr 24, 2017 •

edited

Loading

fredericDelaporte Apr 11, 2017 •

edited

Loading

hazzik Apr 24, 2017 •

edited

Loading

hazzik Apr 24, 2017 •

edited

Loading

hazzik commented Apr 24, 2017 •

edited

Loading

fredericDelaporte commented Apr 24, 2017 •

edited

Loading

fredericDelaporte commented Sep 9, 2017 •

edited

Loading

fredericDelaporte left a comment •

edited

Loading

fredericDelaporte Sep 9, 2017 •

edited

Loading

fredericDelaporte Sep 9, 2017 •

edited

Loading