From: Steve Ebersole
Sent: Tuesday, June 09, 2009 6:02 PM
On Tue, 2009-06-09 at 13:57 -0700, Daniel Pitts wrote:
> I'm new to the list, so please forgive me if I miss some common
> netiquette that is expected on this list.
> I'd like to try to create a patch to solve 869, as well as support
> querying of collections of composite types.
> First, are there any guidelines of what I should and shouldn't do?
> I'd love to clean up the implementation of CriteriaQueryTranslator
> while I'm working in there, but if that would disqualify my patch,
> then of course I should avoid that ;-)
It is best to isolate fixes and cleanup. That way we know
what exactly you did to fix an issue as opposed to cosmetic
changes and can inspect them separately. Feel free to attach both.
sense. If I submit a patch that basically refactors the CQT
class, what might be considered when deciding on inclusion?
> Second, I'm having a little trouble finding the metadata I need to
> implement CriteriaQueryTranslator.getColumns() and
> CriteriaQueryTranslator.getType() for composite
collections. By that
> point, I have access to: CollectionPersister, propertyName, and
> sqlAlias. CollectionPersister.getElementType() returns a
> that appears to be empty.
1) I assume you mean ComponentType (I don't know of a CompositType)
correct. Typo on my part.
2) what do you mean by empty?
I mean the propertyNames,
propertyTypes, etc.. Are all empty arrays.
Maybe I've configured something incorrectly.
I've added to the testsuite what I think will prove my changes correct.
Would it make sense to post a patch here that only has my changes to the
Is this a criterion/restriction you are trying to apply?
It can be, but it also may
be a Projection. I'm hoping that I can stick
to modifying only the CriteriaQueryTranslator class, but if I need to
dive deeper, then so be it.