Re: Issue 367 in morphia: Support entities without a no-arg constructor

[mor...@googlecode.com]

Comment #2 on issue 367 by johan.ha...@gmail.com: Support entities without
a no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

I've created a patch for this.

Attachments:
Added_Objenesis_to_allow_for_no-default_constructor_instantiation.patch
2.1 KB

[mor...@googlecode.com]

Comment #3 on issue 367 by scotthernandez: Support entities without a
no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

Johan, thanks for the patch but adding this dependency is not going to
happen.

You can do this yourself by replacing the DefaultCreator with your own
ObjectFactory:
http://code.google.com/p/morphia/source/browse/trunk/morphia/src/main/java/com/google/code/morphia/ObjectFactory.java

If you would like to make this an "extension" it would make more sense.

[mor...@googlecode.com]

Comment #4 on issue 367 by johan.ha...@gmail.com: Support entities without

a no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

To make it an extension was my first intention as well but unfortunately
there are hard references to DefaultCreator#createInst(..) which is a
static method. Until this is resolved it's not possible to create an
extension (or am I wrong?)

However the dependency is relatively small and it would be possible to
embed it in the Morphia code.

There's another way though that we're using in PowerMock by using a
ReflectionFactory. Is not guaranteed to work on all JVM's but no one has
ever complained about it failing in PowerMock. Many JVM vendors does indeed
implement this class for compliance. Even if it shouldn't work on all JVM's
the new patch just throws an MappingException if fails so it shouldn't be
worse than what we get from Morphia today. XStream also uses this approach
to avoid requiring a default ctor.

Attachments:

Use_ReflectionFactory_to_allow_for_no-default_constructor_instantiation.patch
2.5 KB

[mor...@googlecode.com]

Comment #5 on issue 367 by scotthernandez: Support entities without a
no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

DefaultCreator is just one implementation, the default one, and you don't
need to use any of that code in your extension; you can completely replace
it.

Can you please provide sample code of what this is fixing, or better yet,
what doesn't work now.

[mor...@googlecode.com]

Comment #6 on issue 367 by johan.ha...@gmail.com: Support entities without

a no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

If you look at line 28 in
com.google.code.morphia.mapping.validation.fieldrules.VersionMisuse it uses
the createInst method statically from the DefaultCreator and this is what
concerns me.

I'm attaching a simple example of why I'd like to see this patch accepted.
If you remove the private ctor Morphia will not be able to map the
persisted entity back to the Account instance. I think this should be
possible without (in my view) cluttering the model with annotations. I want
the state in the Account to be immutable and thus I don't want setters and
having a non-default constructor is a good way of achieving this.

[mor...@googlecode.com]

Comment #7 on issue 367 by johan.ha...@gmail.com: Support entities without

a no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

Sorry, here's the attachment.

Attachments:
Account.java 570 bytes

[mor...@googlecode.com]

Comment #8 on issue 367 by martin.grotzke: Support entities without a
no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

Btw, I was thinking more about s.th. like jacksons @JsonCreator:
http://wiki.fasterxml.com/JacksonFeatureCreators

Yes, it's another annotation, but it would integrate well with the existing
morphia annotations.

[mor...@googlecode.com]

Comment #9 on issue 367 by johan.ha...@gmail.com: Support entities without

a no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

For technical reasons (if you're using a JVM that doesn't include the
ReflectionFactory class) I agree that having such an annotation would be
beneficial. But I believe that you should try to be as non-intrusive to
your domain/entity model as possible (of course it's always a trade-off),
especially when the framework _can_ fix the issues for us. To me this issue
is exclusively a technical issue that can be resolved by the framework
itself without user intervention. I think that XStream is a good example of
a mapping framework that is non-intrusive. It (almost) doesn't force you to
follow some predefined coding model such as using getters and setters or
using a default constructor.

I'm new to Morpia so I don't really know the philosophy behind it yet but I
could very well imagine having both the ReflectionFactory to instantiate
classes without using a constructor _and_ having annotations as fallback.
Although I think the ReflectionFactory approach will be sufficient for the
vast majority of users.

[mor...@googlecode.com]

Comment #10 on issue 367 by dgg...@gmail.com: Support entities without a
no-arg constructor
http://code.google.com/p/morphia/issues/detail?id=367

When just a couple of your fields are final but there are many fields in
total, using a factory is (IMO) much more painful than using an
annotation. Perhaps I'm missing a way to use morphia to map the remainder
of the fields? If so, I'd love to know how to do so.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings