New StaticProxyFactoryFactory #1451

hazzik · 2017-11-22T11:03:27Z

No description provided.

hazzik · 2017-11-22T11:44:35Z

At the current state of the PR, performance improvement is 16.8% on the data from #1446

hazzik · 2017-11-22T20:43:14Z

src/NHibernate/Proxy/Poco/BasicLazyInitializer.cs

@@ -81,10 +81,6 @@ public virtual object Invoke(MethodInfo method, object[] args, object proxy)
 				{
 					return null;
 				}
-				else if ("get_HibernateLazyInitializer".Equals(methodName))


We, probably, need to revert this change if we want to support [legacy] proxy factories.

Yes, and it looks to me there is no easy way to obsolete this code path: I do not think we can know there if the property implementation is itself proxied or not.

fredericDelaporte

I am not confortable yet about my understanding of those proxies inner working. I am not used to the emit IL stuff either. But I think it is a welcomed change.

src/NHibernate/Proxy/DynamicProxy/DefaultMethodEmitter.cs

fredericDelaporte · 2017-11-23T12:31:30Z

src/NHibernate/Proxy/DynamicProxy/NHibernateProxyImplementor.cs

+			var IL = getMethod.GetILGenerator();
+
+			// This is equivalent to:
+			// get { return (INHibernateProxy)__interceptor; }


Comment should be // get { return (ILazyInitializer)__interceptor; }

fredericDelaporte · 2017-11-23T13:01:51Z

src/NHibernate/Proxy/Poco/BasicLazyInitializer.cs

@@ -81,10 +81,6 @@ public virtual object Invoke(MethodInfo method, object[] args, object proxy)
 				{
 					return null;
 				}
-				else if ("get_HibernateLazyInitializer".Equals(methodName))


Yes, and it looks to me there is no easy way to obsolete this code path: I do not think we can know there if the property implementation is itself proxied or not.

hazzik · 2017-11-25T11:45:34Z

Ok, I've finally come up with what I want to achieve with this PR. As all method implementations are known at the compile time, it would much beneficial to generate "static" proxies. This means that there will be no interceptors involved. This will allow removing the unnecessary overhead of a heavy reflection manipulations. The public classes and interfaces from DynamicProxy namespace will remain unchanged but marked as obsoleted in 5.1 and removed in 6.0. This will allow clients who use custom proxy factories with parts of our implementations to migrate/update their changes. We will also need to update NHibernateProxyGenerator (NHPG) to use the new approach.

hazzik · 2017-12-01T10:20:15Z

Finally was able to run a benchmark. With the current state of the PR memory usage has dropped to

NHibernate v5.0.0.0 (v5.0.3.0) : 228 951 KB (234 446 840 bytes) (more than half of 5.0.3)

And execution time has fell for about 30% (2s vs 2.6s on my laptop)

hazzik · 2017-12-02T12:50:49Z

Final number:

241 491 KB

hazzik · 2017-12-03T12:29:32Z

src/NHibernate/Proxy/DefaultProxyFactory.cs

+			var result = Activator.CreateInstance(proxyType);
+			var proxy = (IProxy) result;
+			proxy.Interceptor = new DefaultDynamicLazyFieldInterceptor();
+			return result;


Changes to this method need to be reverted for now.

hazzik · 2017-12-03T12:29:51Z

src/NHibernate/Proxy/AbstractProxyFactory.cs

@@ -10,8 +11,9 @@ namespace NHibernate.Proxy
 	/// <summary>
 	/// Convenient common implementation for ProxyFactory
 	/// </summary>
-	public abstract class AbstractProxyFactory: IProxyFactory
+	public abstract class AbstractProxyFactory: IProxyFactory, ISerializable


The easiest (and I think the correct) way to serialize a proxy was to serialize its proxy factory.

Adding the ISerializable interface to a public non sealed type is a gray area breaking change in my opinion, because all descendant need then to implement the deserialization constructor (and may need to extend the get data method for including their own additional data).
It is not binary breaking though, so maybe it can be accepted for a minor.

We should at least flag this as a possible breaking change. (I have just created the label for #1461.) In release notes we would have to state that descendants of AbstractProxyFactory must now provide the deserialization constructor and need to override GetObjectData if they have additional state data to serialize.

I now realize this point is a possible breaking change: static proxies are serialized without their entity state, even if they were initialized. They are always de-serialized in un-initialized state.

So, for proxies de-serialized by a session de-serialization, using them will always triggers a lazy load even if they were serialized while already being loaded. It looks to me dynamic proxies would not trigger a lazy load in that case.

For proxies directly serialized/de-serialized, with dynamic proxies their de-serialized state should be usable if they were initialized before serialization, while static proxies would be always un-initialized and un-usable because no more bound to a session.

Maybe a way to get the initializer _target instance should be added, for serializing it along the other proxy data, thus allowing to supply it back to the proxy on deserialization.

src/NHibernate/Proxy/DynamicProxy/DefaultMethodEmitter.cs

hazzik · 2017-12-03T12:31:55Z

src/NHibernate/Proxy/DynamicProxy/NHibernateProxyObjectReference.cs

+		[SecurityCritical]
+		public object GetRealObject(StreamingContext context)
+		{
+			return _proxyFactory.GetProxy(_identifier, null);


null here is for ISessionImplementation. On deserialization, the PersistanceContext will re-associate the session with the proxy. The proxy does support having a null session.

If the code previously was never calling this method with null as the session parameter (that seems to be the case), it may be a breaking changed for a custom IProxyFactory. The contract does not state anything explicit about this parameter nullability. Should we care for implementors who would not support receiving it null?

it may be a breaking changed for a custom IProxyFactory

In this codepath there will be no custom IProxyFactory.

The LazyInitializer underneath does support accepting null.

So, answer is no.

gliljas · 2017-12-03T19:54:11Z

@hazzik Well done! I will try to find some time to review it properly this week (I sing in a choir, and it's Christmas time, so like six rehearsals this week.. :) )

fredericDelaporte · 2017-12-05T15:36:22Z

src/NHibernate.Test/NHSpecificTest/NH3954/EqualsFixture.cs

@@ -48,9 +49,9 @@ public void TypeInequality()
 		[Test]
 		public void InterfaceEquality()
 		{
-			var entry1 = new ProxyCacheEntry(typeof(Entity1), new[] { typeof(INHibernateProxy), typeof(IProxy) });
+			var entry1 = new ProxyCacheEntry(typeof(Entity1), new[] { typeof(INHibernateProxy), typeof(IFieldInterceptorAccessor) });


Change will conflict with #1454.

As #1451 now uses completely different approach, I’m going to remove from there changes related to this PR.

Seems not fully done. I guess you want to merge #1454 then rebase this PR for doing the cleanup.

It’s not “not fully done” it’s simply “not done”. Yeah, going to rebase on #1454 then cleanup

fredericDelaporte · 2017-12-05T15:36:47Z

src/NHibernate.Test/NHSpecificTest/NH3954/ProxyCacheFixture.cs

 using NHibernate.Proxy;
 using NHibernate.Proxy.DynamicProxy;
 using NUnit.Framework;

 namespace NHibernate.Test.NHSpecificTest.NH3954
 {
-	[TestFixture, Explicit("Demonstrates bug impact on cache, but which tests will fail is a bit unpredictable")]
+	[TestFixture, Explicit("Demonstrates bug impact on cache, but which tests will fail is a bit unpredictable"), Obsolete]


Same as previous comment, same for IProxyCache, ProxyCache, ProxyCacheEntry, ProxyFactory and some other places.

fredericDelaporte · 2017-12-05T15:44:02Z

src/NHibernate/Proxy/AbstractProxyFactory.cs

@@ -10,8 +11,9 @@ namespace NHibernate.Proxy
 	/// <summary>
 	/// Convenient common implementation for ProxyFactory
 	/// </summary>
-	public abstract class AbstractProxyFactory: IProxyFactory
+	public abstract class AbstractProxyFactory: IProxyFactory, ISerializable


Adding the ISerializable interface to a public non sealed type is a gray area breaking change in my opinion, because all descendant need then to implement the deserialization constructor (and may need to extend the get data method for including their own additional data).
It is not binary breaking though, so maybe it can be accepted for a minor.

We should at least flag this as a possible breaking change. (I have just created the label for #1461.) In release notes we would have to state that descendants of AbstractProxyFactory must now provide the deserialization constructor and need to override GetObjectData if they have additional state data to serialize.

fredericDelaporte · 2017-12-05T15:47:13Z

src/NHibernate/Proxy/AbstractProxyFactory.cs

+		{
+			EntityName = (string) info.GetValue(nameof(EntityName), typeof(string));
+			PersistentClass = (System.Type) info.GetValue(nameof(PersistentClass), typeof(System.Type));
+			Interfaces = (System.Type[]) info.GetValue(nameof(Interfaces), typeof(System.Type[]));


Will mandate an update of #1425 if merged before, or will need to be changed accordingly to #1425 otherwise.

I don’t think that proxies would even work in (all) netstandard as Reflection.Emit is a netstandard 1.x + platforms rather than a pure netstandard.

#1425 would not really help here as I’m seraializing a MethodInfo as well.

MethodInfo in covered in #1425. I didn't think NHibernate on .netstandard worked without things like DynamicProxies. The target isn't iOS (which requires static compilation), but the targets able to run .Net Core.

Update: Is this pull request going to provide a compile-time proxy generation ability?

Update: Is this pull request going to provide a compile-time proxy generation ability?

It looks to me as being the purpose of https://github.com/nhibernate/NHibernate.ProxyGenerators. I do not expect this to change. Moreover Alexander had mentioned this project will need an update after this PR.

I have plans to include proxy generators into the core (as a tool + msbuild targets) to provide support for compile time proxies for the platforms which do not support runtime proxies. But not in this PR, and, most likely, not in this milestone.

fredericDelaporte · 2017-12-05T15:55:23Z

src/NHibernate/Proxy/DefaultProxyFactory.cs

-				return (INHibernateProxy) proxyInstance;
+				var proxyBuilder = new NHibernateProxyBuilder(GetIdentifierMethod, SetIdentifierMethod, ComponentIdType, OverridesEquals);
+				var cacheEntry = new ProxyCacheEntry(IsClassProxy ? PersistentClass : typeof(object), Interfaces);
+				var proxyActivator = Cache.GetOrAdd(cacheEntry, pke => CreateProxyActivator(proxyBuilder, pke));


When the proxyActivator is retrieved from the cache, the proxyBuilder has then be created for nothing. I think it should be inlined into the GetOrAdd() second argument lambda.

fredericDelaporte · 2017-12-05T17:35:08Z

src/NHibernate/Proxy/AbstractProxyFactory.cs

@@ -51,5 +68,16 @@ public virtual object GetFieldInterceptionProxy(object instanceToWrap)
 		{
 			throw new NotSupportedException();
 		}
+
+		public virtual void GetObjectData(SerializationInfo info, StreamingContext context)


Missing [SecurityCritical] attribute.

fredericDelaporte · 2017-12-05T17:42:14Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -206,7 +189,7 @@ private static ConstructorBuilder DefineConstructor(TypeBuilder typeBuilder, Sys
 			return constructor;
 		}

-		private static void ImplementGetObjectData(System.Type baseType, System.Type[] baseInterfaces, TypeBuilder typeBuilder, FieldInfo interceptorField)
+		internal static void ImplementGetObjectData(System.Type baseType, IReadOnlyCollection<System.Type> baseInterfaces, TypeBuilder typeBuilder, FieldInfo interceptorField)


Related subject but not introduced by this PR: I wonder if in the case of dynamic code we should also add that [SecurityCritical] attribute to GetObjectData. I am not finding much information on the subject.

We should, but I don't want to touch the DynamicProxy namespace

fredericDelaporte · 2017-12-05T17:47:37Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			var parameterTypes = new[] {typeof (SerializationInfo), typeof (StreamingContext)};
+
+			MethodBuilder methodBuilder =
+				typeBuilder.DefineMethod("GetObjectData", attributes, typeof (void), parameterTypes);


Here too, should we add SecurityCritical?

fredericDelaporte · 2017-12-05T17:53:43Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -257,7 +240,7 @@ private static void ImplementGetObjectData(System.Type baseType, System.Type[] b
 			IL.Emit(OpCodes.Ret);
 		}

-		private static void DefineSerializationConstructor(TypeBuilder typeBuilder, FieldInfo interceptorField, ConstructorBuilder defaultConstructor)
+		internal static void DefineSerializationConstructor(TypeBuilder typeBuilder, FieldInfo interceptorField, ConstructorBuilder defaultConstructor)


Related subject but not introduced by this PR: Is the method body emitted here useful? Since it is supposed to be deserialized by ProxyObjectReference. It should be implemented the same way than NHibernateProxyBuilder.ImplementDeserializationConstructor I think.

I don't want to touch/fix/change DynamicProxy namespace other than for major bugs. It's working, so let it be this way. The namespace itself is going to be retired in 6.0

fredericDelaporte · 2017-12-05T18:03:44Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			IL.Emit(OpCodes.Ldarg_1);
+			IL.Emit(OpCodes.Ldarg_2);
+
+			IL.Emit(OpCodes.Callvirt, typeof(ISerializable).GetMethod(nameof(ISerializable.GetObjectData)));


So we have now two different ways of implementing the an IObjectReference with proxies, since the one for DynamicProxy.ProxyFactory does not delegate the GetObjectData to DynamicProxy.ProxyObjectReference. I prefer the pattern you have done for NHibernateProxyObjectReference, but then we should align ProxyObjectReference on the same pattern.

Not going to bother with DynamicProxy namespace. Going to obsolete it after converting lazy properties proxies to the same approach.

hazzik · 2017-12-08T00:08:01Z

I've cleaned the PR addressing some of the review comments.

hazzik · 2017-12-08T11:05:44Z

Now it's implemented as a completely new feature.

- The factory generates high-efficient static proxies (no interceptor)

fredericDelaporte · 2017-12-12T10:34:53Z

I am not forgetting it and was intending to look it again today anyway.

fredericDelaporte

Shouldn't DefaultProxyFactoryFactory, DefaultProxyFactory,DefaultLazyInitializer, BasicLazyInitializer be obsoleted?

fredericDelaporte · 2017-12-12T10:41:30Z

src/NHibernate/Bytecode/StaticProxyFactoryFactory.cs

+{
+	public class StaticProxyFactoryFactory : IProxyFactoryFactory
+	{
+		internal static StaticProxyFactoryFactory Instance = new StaticProxyFactoryFactory();


For enforcing the singleton pattern, I would define a private default constructor.

This is a small memory optimization. I don't want to enforce the singleton pattern here. And, in fact, we cannot enforce it, as StaticProxyFactoryFactory can be manually configured as a proxy factory factory and will require the public constructor to be creatable by reflection.

Yes, I forgot to think about configuration.

fredericDelaporte · 2017-12-12T10:48:23Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -21,11 +21,11 @@ public sealed class ProxyFactory
 	{
 		internal static readonly ConcurrentDictionary<ProxyCacheEntry, TypeInfo> _cache = new ConcurrentDictionary<ProxyCacheEntry, TypeInfo>();

-		private static readonly ConstructorInfo defaultBaseConstructor = typeof(object).GetConstructor(new System.Type[0]);
+		internal static readonly ConstructorInfo defaultBaseConstructor = typeof(object).GetConstructor(new System.Type[0]);


Since DynamicProxy is supposed to be removed in some future further proxy refactoring, I would tend to duplicate such a field in NHibernateProxyBuilder rather than sharing it.
Otherwise I would also consider putting it in ReflectionCache.

Same for setType field.

fredericDelaporte · 2017-12-12T10:52:01Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -139,7 +139,7 @@ private IEnumerable<MethodInfo> GetProxiableMethods(System.Type type, IEnumerabl
 					.Distinct();
 		}

-		private static ConstructorBuilder DefineConstructor(TypeBuilder typeBuilder, System.Type parentType)
+		internal static ConstructorBuilder DefineConstructor(TypeBuilder typeBuilder, System.Type parentType)


Not used outside of ProxyFactory, could stay private.

fredericDelaporte · 2017-12-12T10:53:14Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -166,7 +166,7 @@ private static ConstructorBuilder DefineConstructor(TypeBuilder typeBuilder, Sys
 			return constructor;
 		}

-		private static void ImplementGetObjectData(System.Type baseType, IReadOnlyCollection<System.Type> baseInterfaces, TypeBuilder typeBuilder, FieldInfo interceptorField)
+		internal static void ImplementGetObjectData(System.Type baseType, IReadOnlyCollection<System.Type> baseInterfaces, TypeBuilder typeBuilder, FieldInfo interceptorField)


Not used outside of ProxyFactory, could stay private.

fredericDelaporte · 2017-12-12T10:54:02Z

src/NHibernate/Proxy/DynamicProxy/ProxyFactory.cs

@@ -217,7 +217,7 @@ private static void ImplementGetObjectData(System.Type baseType, IReadOnlyCollec
 			IL.Emit(OpCodes.Ret);
 		}

-		private static void DefineSerializationConstructor(TypeBuilder typeBuilder, FieldInfo interceptorField, ConstructorBuilder defaultConstructor)
+		internal static void DefineSerializationConstructor(TypeBuilder typeBuilder, FieldInfo interceptorField, ConstructorBuilder defaultConstructor)


Not used outside of ProxyFactory, could stay private.

fredericDelaporte · 2017-12-12T12:46:57Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			}
+			else if (_componentIdType != null && _componentIdType.IsMethodOf(method))
+			{
+				ImplementCallMethodOnEmbeddedComponentId(typeBuilder, method, lazyInitializerField);


I have not seen any implementation of IAbstractComponentType.IsMethodOf yielding anything else than false, so this code path looks untested. I know this comes from BasicLazyInitializer logic, but was this part still relevant?

Could it be component id classes were supposed to be themselves proxified? But I do not see where this could happen. Otherwise is this something meant to allow some special method of the entity, supposed to just forward on the id component, to be called without initializing the proxy?

(On Hibernate's side, there is an implementation of IAbstractComponentType.IsMethodOf yielding something else than false (indeed componentTuplizer.isMethodOf(method)), on EmbeddedComponentType. But this override is lacking on NHibernate's side. And component tuplizer is lacking the method too on NHibernate's side. On Hibernate's side it has a non falsy implementation on PojoComponentTuplizer. But I have not checked in which case the method argument could actually belong to the component, and I think there are more things lacking for this feature on NHibernate's side.)

Not sure what is that, or how it's supposed to be used. I've copied this from DefaultProxyFactory. Do you think that this path needs to be removed?

With what I have seen on Hibernate's side, it now looks to me as something partially ported, causing it to very likely never have any usage. Fully ascertaining this would require a bit more digging on Hibernate's side to see in which cases it serves.
I am always for removing useless code, but since it does not cause any harm, it is also not really worth it to dig more for checking it can really be removed without any risk.

So if you are not sure about it either, it is going to stay for now.

fredericDelaporte · 2017-12-12T12:53:55Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			IL.Emit(OpCodes.Ldarg_0);
+			IL.Emit(OpCodes.Call, baseConstructor);
+
+			IL.Emit(OpCodes.Ldarg_0);


I would add before:

// __lazyInitializer == lazyInitializer;

fredericDelaporte · 2017-12-12T12:54:34Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			IL.Emit(OpCodes.Ldarg_1);
+			IL.Emit(OpCodes.Stfld, lazyInitializerField);
+
+			IL.Emit(OpCodes.Ldarg_0);


I would add before:

// __proxyInfo == proxyInfo;

fredericDelaporte · 2017-12-12T13:05:36Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			IL.Emit(OpCodes.Call, ReflectionCache.TypeMethods.GetTypeFromHandle);
+			IL.Emit(OpCodes.Callvirt, ProxyFactory.setType);
+
+			//this.__proxyInfo


I would add before:

// (new NHibernateProxyObjectReference(__proxyInfo, __lazyInitializer.Identifier)).GetObjectDataMethod(info, context);

fredericDelaporte · 2017-12-12T13:22:44Z

src/NHibernate/Proxy/NHibernateProxyBuilder.cs

+			/*
+			 set 
+			 {
+				this.__lazyInitializer.Initialize();


Indeed should be prepended with:

if (this.__lazyInitializer == null) return base.<Method> (args..)

Same for next two methods.

hazzik · 2017-12-12T21:48:10Z

Shouldn't DefaultProxyFactoryFactory, DefaultProxyFactory,DefaultLazyInitializer, BasicLazyInitializer be obsoleted?

Maybe in a next PR.

Follow up to nhibernate#1451 for still testing NH-2622, NH-2628 and nhibernate#1389

Follow up to #1451 for still testing NH-2622, NH-2628 and #1389

hazzik changed the title ~~Proxy refactoring~~ [WIP] Proxy refactoring Nov 22, 2017

hazzik force-pushed the proxy-refactoring branch 2 times, most recently from 46477d6 to 5822c8e Compare November 22, 2017 11:26

hazzik commented Nov 22, 2017

View reviewed changes

fredericDelaporte reviewed Nov 23, 2017

View reviewed changes

hazzik mentioned this pull request Nov 25, 2017

Fix ProxyFactory cache #1454

Merged

hazzik force-pushed the proxy-refactoring branch from bae9e88 to eec3d10 Compare December 2, 2017 08:24

hazzik changed the title ~~[WIP] Proxy refactoring~~ Static INHibernateProxy Dec 2, 2017

hazzik changed the title ~~Static INHibernateProxy~~ Implement static INHibernateProxy Dec 2, 2017

hazzik changed the title ~~Implement static INHibernateProxy~~ DefaultProxyFactory generates static proxies for entities Dec 2, 2017

hazzik requested review from gliljas and fredericDelaporte December 2, 2017 12:52

hazzik added c: ByteCode providers p: Major t: Improvement labels Dec 3, 2017

hazzik added this to the 5.1 milestone Dec 3, 2017

hazzik commented Dec 3, 2017

View reviewed changes

fredericDelaporte reviewed Dec 5, 2017

View reviewed changes

hazzik force-pushed the proxy-refactoring branch 4 times, most recently from 2575b33 to 8d4df90 Compare December 8, 2017 00:05

nhibernate deleted a comment from fredericDelaporte Dec 8, 2017

hazzik force-pushed the proxy-refactoring branch from e4db57d to cc1222c Compare December 8, 2017 10:10

hazzik added t: New Feature and removed t: Improvement labels Dec 8, 2017

hazzik force-pushed the proxy-refactoring branch from e899fdb to 6c0ec4c Compare December 8, 2017 11:09

Implement new StaticProxyFactoryFactory

c48beb8

- The factory generates high-efficient static proxies (no interceptor)

hazzik force-pushed the proxy-refactoring branch from 6c0ec4c to c48beb8 Compare December 8, 2017 11:13

hazzik changed the title ~~DefaultProxyFactory generates static proxies for entities~~ New StaticProxyFactoryFactory Dec 8, 2017

hazzik added 5 commits December 11, 2017 09:24

Fix tests

9cc5161

Merge branch 'master' into proxy-refactoring

de78104

Fix comments

b4bfc90

Code cleanup

bf80568

Fix comments

64e4b57

hazzik assigned fredericDelaporte Dec 12, 2017

fredericDelaporte reviewed Dec 12, 2017

View reviewed changes

hazzik added 2 commits December 13, 2017 10:48

Code review fixes

fa51673

Mark another method as private

01ed700

fredericDelaporte approved these changes Dec 12, 2017

View reviewed changes

hazzik merged commit bc30eb4 into nhibernate:master Dec 13, 2017

hazzik deleted the proxy-refactoring branch December 13, 2017 00:04

hazzik added the r: Fixed label Dec 13, 2017

fredericDelaporte mentioned this pull request May 27, 2018

Lazy properties static proxy #1709

Merged

fredericDelaporte referenced this pull request Jul 5, 2018

Obsolete dynamic proxies

5d77746

cremor mentioned this pull request Jul 16, 2018

Default value of 'proxyfactory.factory_class' in the documentation #1799

Closed

fredericDelaporte added a commit to fredericDelaporte/nhibernate-core that referenced this pull request Oct 24, 2018

Test ref and out methods with static proxy

114a868

Follow up to nhibernate#1451 for still testing NH-2622, NH-2628 and nhibernate#1389

fredericDelaporte mentioned this pull request Oct 24, 2018

Test ref and out methods with static proxy #1887

Merged

fredericDelaporte added a commit that referenced this pull request Oct 25, 2018

Test ref and out methods with static proxy

41782de

Follow up to #1451 for still testing NH-2622, NH-2628 and #1389

fredericDelaporte mentioned this pull request Mar 13, 2019

Possible wrong proxy determination which could lead to a sql exception #2052

Closed

New StaticProxyFactoryFactory #1451

New StaticProxyFactoryFactory #1451

Conversation

hazzik commented Nov 22, 2017

hazzik commented Nov 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fredericDelaporte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hazzik commented Nov 25, 2017 • edited Loading

hazzik commented Dec 1, 2017 • edited Loading

hazzik commented Dec 2, 2017

hazzik Dec 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gliljas commented Dec 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ngbrown Dec 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hazzik commented Dec 8, 2017

hazzik commented Dec 8, 2017

fredericDelaporte commented Dec 12, 2017

fredericDelaporte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hazzik Dec 12, 2017 • edited Loading

Choose a reason for hiding this comment

fredericDelaporte Dec 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fredericDelaporte Dec 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fredericDelaporte Dec 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hazzik commented Dec 12, 2017 • edited Loading

hazzik commented Nov 25, 2017 •

edited

Loading

hazzik commented Dec 1, 2017 •

edited

Loading

hazzik Dec 3, 2017 •

edited

Loading

ngbrown Dec 7, 2017 •

edited

Loading

hazzik Dec 12, 2017 •

edited

Loading

fredericDelaporte Dec 12, 2017 •

edited

Loading

fredericDelaporte Dec 12, 2017 •

edited

Loading

fredericDelaporte Dec 12, 2017 •

edited

Loading

hazzik commented Dec 12, 2017 •

edited

Loading