tracker issue : CF-4053554

select a category, or use search below
(searches all categories and all time range)
Title:

Persistent components shall not need a persistent or embeddable attribute when a mapping file is defined

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): Alexandre Potvin Latreille / Alexandre Potvin Latreille (Alexandre Potvin Latreille)

Created: 09/10/2015

Components: ORM Support

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / All users will encounter

Locale/System: ALL / Win 2008 Server x64

Vote Count: 1

Problem Description:

It's currently impossible to make components completely persistence-ignorant because the persistent/embeddable attributes have to be defined on a component despite the fact that a mapping file exists.

Steps to Reproduce:

Create an Hibernate mapping file for a component, but do not add persistent="true" in the component's definition.

Actual Result:

coldfusion.orm.hibernate.CFCTuplizer$CFCInstantiationException: CFC axp058.coldfusion.orm_collection_mapping_tests.Artist could not be initialized

Expected Result:

A component shall be identified as a persistent component if a mapping file exists for that component. The same goes for any embeddable components that may be referenced in a mappings file.

Any Workarounds:

I haven't found any workaround.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4053554

External Customer Info:
External Company:  
External Customer Name: Alexandre Potvin Latreille
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

This makes sense. +1 Vote must be between 25 and 4000 characters
Vote by External U.
5934 | September 13, 2015 04:57:19 PM GMT
On the face of it looks a fair enhancement. However, objects managed by an ORM engine are a little special as compared to regular CFCs - An object must have an ID (simple or complex) - It must override equals and hashcode method using the identifier - It must be serializable. Because of this special behavior, the internal Java class is different for ORM cfcs and the differentiation happens based on the 'persistent' attribute.
Comment by Rupesh K.
5921 | September 13, 2015 09:57:36 PM GMT
@Rupesh Kumar "An object must have an ID (simple or complex)" That's why this case is already covered in mappings file validation... An identity is usually a business concern and having one within a CFC certainly doesn't leak infrastructure details; what does is having to use the fieldtype="id" attribute on that identity property. "and the differentiation happens based on the 'persistent' attribute." Why can't the differentiation be based on whether there's a mapping or not rather than whether there's a persistent attribute or not? That's just a technical challenge related to your current ORM implementation.
Comment by External U.
5922 | September 14, 2015 08:14:42 AM GMT
*BUMP*
Comment by External U.
5923 | September 20, 2015 07:06:20 PM GMT
The framework *requires* these attributes to be present on the CFC to work.
Comment by Rupesh K.
5924 | September 22, 2015 08:48:31 AM GMT
@Rupesh Kumar That's an implementation detail of the framework and I'm sure it could be changed. With the replies I received on various issues so far I really have the feeling that Adobe is always looking for reasons not to fulfill requests before even trying to find solutions...
Comment by External U.
5925 | September 22, 2015 10:44:16 AM GMT
{quote} "and the differentiation happens based on the 'persistent' attribute." Why can't the differentiation be based on whether there's a mapping or not rather than whether there's a persistent attribute or not? That's just a technical challenge related to your current ORM implementation. {quote} I think a reasonable response to this comment is not too much to ask. Simply restating it using different wording is a bit of a waste of everyone's time.
Comment by External U.
5926 | September 22, 2015 11:44:48 AM GMT
Theoretically the differentiation can be made based on whether the mapping is defined or not, but that is not practical. There are many reasons - one of the reason is modularity of framework and the performance of object creation. Object creation using "new" or createObject(), should never make a call to the ORM framework. I am curious - what would be the reason for not putting persistent attribute on CFC?
Comment by Rupesh K.
5927 | September 23, 2015 09:42:30 AM GMT
Unit testing is the first and most obvious one I can think of. You don't want all the trappings of the hibernate stuff getting in the way when one is just running tests. I can't see why you can't "reverse" the logic. When a CFC is first instantiated you create metadata for it, which as far as I know is not re-fetched on subsequent object creation? So in that initial object creation & metadata creation you do the opposite of what you do for persistent=true: you instead look for the mapping, and then *in your metadata* set "yeah, this one is persisted". A wee bit of a hit on first object creation, but the work only needs to be done once, yes?
Comment by External U.
5928 | September 23, 2015 10:00:08 AM GMT
(Oh, obviously I'm speculating a bit there, so might be talking ballocks)
Comment by External U.
5929 | September 23, 2015 10:00:34 AM GMT
Unit testing is a very good reason, but avoiding to pollute domain logic with infrastructure concerns is my primary motivation.
Comment by External U.
5930 | September 30, 2015 10:29:50 AM GMT
Indeed. I suppose this is the whole reason that the mapping file exists in the first place: to keep that stuff away from the code. Do Java classes need annotations in them when using Hibernate? Or does the mapping file cover the whole lot?
Comment by External U.
5931 | September 30, 2015 10:31:55 AM GMT
@Adam As far as I know annotations aren't mandatory with Hibernate in Java. The only trade-off would be to have a private no-arguments constructor. That makes Hibernate one of the best ORMs for Java DDD practitioners, since you can focus on modeling the domain and only care about persistence at the very end.
Comment by External U.
5932 | September 30, 2015 03:17:56 PM GMT
@Rupesh, Will this be reconsidered?
Comment by External U.
5933 | October 17, 2015 09:21:52 AM GMT