DBRefs break when a custom collection name is used to save referenced entities

[jyemin]

This is Issue 336 moved from a Google Code project.
Added by 2011-10-28T20:35:16.000Z by chanh.d...@socialdynamx.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Low

Original description

What version are you using? (Morphia/Driver/MongoDB) 0.99

Please include a stack trace below:

Exception in thread "main" java.lang.RuntimeException: collection names don't match for key and class: Triangle != Test Triangle
    at com.google.code.morphia.DatastoreImpl.getByKey(DatastoreImpl.java:537)
    at com.google.code.morphia.mapping.lazy.proxy.SerializableCollectionObjectReference.fetch(SerializableCollectionObjectReference.java:47)
    at com.google.code.morphia.mapping.lazy.proxy.AbstractReference.get(AbstractReference.java:42)
    at com.thoughtworks.proxy.toys.delegate.DelegatingInvoker.delegate(DelegatingInvoker.java:127)
    at com.thoughtworks.proxy.toys.hotswap.HotSwappingInvoker.delegate(HotSwappingInvoker.java:115)
    at com.thoughtworks.proxy.toys.hotswap.HotSwappingInvoker.invoke(HotSwappingInvoker.java:87)
    at com.google.code.morphia.mapping.lazy.NonFinalizingHotSwappingInvoker.invoke(NonFinalizingHotSwappingInvoker.java:25)
    at com.thoughtworks.proxy.factory.AbstractProxyFactory$CoincidentalInvocationHandlerAdapter.invoke(AbstractProxyFactory.java:96)
    at $java.util.ArrayList$$EnhancerByCGLIB$$39bf8312.get(<generated>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.thoughtworks.proxy.toys.delegate.DelegatingInvoker.invokeOnDelegate(DelegatingInvoker.java:164)
    at com.thoughtworks.proxy.toys.delegate.DelegatingInvoker.invoke(DelegatingInvoker.java:116)
    at com.thoughtworks.proxy.toys.dispatch.DispatchingInvoker.invoke(DispatchingInvoker.java:127)
    at com.thoughtworks.proxy.factory.AbstractProxyFactory$CoincidentalInvocationHandlerAdapter.invoke(AbstractProxyFactory.java:96)
    at $java.util.ArrayList$$EnhancerByCGLIB$$c087e85b.get(<generated>)
    at Rectangle.getF(Rectangle.java:60)
    at morp.main(morp.java:231)

Hi, im new to morphia. And i have an issue with lazy load and dynamic collection name.
I have some classes for testing.

class Rectangle extends Shapes {
    @Reference
    private Triangle friend;
    ...
}

class Triangle extends Shapes {
    ...
}

This works fine if I dont save Triangle in a dynamic collection name. (eg. "Test Triangle" instead of let Morphia save them in Triangle). Changing the collection name wont work because the Rectangle will contain something like this $ref : Triangle , $id : 1234567890. So before inserting. i come in and change this to $ref : Test Triangle , $id : 1234567890.

This works correctly. but I want to have the reference to be lazy (eg. @reference(lazy=true)). after added the lazy=true to @reference, I start getting the above error.

This is where Im stucked. Why is it able to match the class without lazy loading. But when lazy loading enabled, it cant match anymore. Is there a way to do this scenario? thanks for your help.

[anthonyjchriste]

Has there been any progress on this? I'm hoping to reference time series data stored in dynamically named collections based on the day. I'm using Morphia 1.1.1. Thanks for the hard work. Morphia has been a joy to work with.

[evanchooly]

I've been giving some thought off and on over the last while. At present, I can't think of any way to resolve these references when dynamically changing the collection used to store the documents. Probably the cleanest way to do so is, is to store only the ID values in your entity and resolve the manually by doing a query against the dynamic collection name.

I can't see, at the moment, how any API change would help fix this without completely cluttering the API. I'm certainly open to suggestions, however.

[evanchooly]

depends on #948