search

google-code-export / morphia

Automatically exported from code.google.com/p/morphia
1 stars 0 forks source link

Support entities without a no-arg constructor #367

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
It would be good to be able to map classes (root beans, not embedded) that do 
not provide a default constructor.

There is @ConstructorArgs, but this can only be applied to fields (and is
only evaluated for mapped fields AFAICS), so this does not do the trick.

The thread on the mailing list: 
http://groups.google.com/group/morphia/browse_thread/thread/764e83a06ef8577

This is actually an improvment, not a defect.

Original issue reported on code.google.com by martin.grotzke on 3 Jan 2012 at 9:48

GoogleCodeExporter commented 9 years ago

Original comment by scotthernandez on 3 Jan 2012 at 3:27

GoogleCodeExporter commented 9 years ago 
I've created a patch for this.

Original comment by johan.ha...@gmail.com on 21 Feb 2012 at 8:00

Attachments:

GoogleCodeExporter commented 9 years ago 
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/g
oogle/code/morphia/ObjectFactory.java

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

Original comment by scotthernandez on 21 Feb 2012 at 1:33

GoogleCodeExporter commented 9 years ago 
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.

Original comment by johan.ha...@gmail.com on 21 Feb 2012 at 2:34

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by scotthernandez on 21 Feb 2012 at 2:48

GoogleCodeExporter commented 9 years ago 
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.

Original comment by johan.ha...@gmail.com on 21 Feb 2012 at 3:03

GoogleCodeExporter commented 9 years ago 
Sorry, here's the attachment.

Original comment by johan.ha...@gmail.com on 21 Feb 2012 at 3:09

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by martin.grotzke on 21 Feb 2012 at 10:29

GoogleCodeExporter commented 9 years ago 
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.

Original comment by johan.ha...@gmail.com on 22 Feb 2012 at 7:12

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dgg...@gmail.com on 2 Apr 2014 at 8:45