I really like Elliot's enhancement idea, and it wouldn't be hard to
implement.

I had also thought about doing something similar to what Bob suggested
below... it may be an interesting challenge, not quite sure on the how, but
it is worth investigating for sure.

Mark

On Tue, Feb 3, 2009 at 1:40 AM, Bob Silverberg <bob.silverb...@gmail.com>wrote:

>
> This is something that I ran across when I started using TQL.  At
> first I wondered why Transfer didn't figure out the type for me, and
> then I realized that Transfer doesn't know to which property a
> particular param is assigned.
>
> So what you're suggesting is that the behaviour of the setParam()
> method be changed, and _if_ a fully qualified property name is passed
> in the type argument that Transfer would do the translation for you?
>
> Sounds reasonable, and I understand that Mark is rewriting the TQL
> parser anyway.  That being the case, why not take it one step further?
>  What if the parser were able to look at where the params were
> specified in the query, thereby match them with their corresponding
> properties, and then do the type lookup thing automatically?  That
> would solve the problem, and not require one to have to specify the
> property name in the type argument of the setParam method.
>
> That doesn't sound like a particularly easy thing to do, but seeing as
> the entire query is being parsed anyway, perhaps it's possible.  No
> doubt Mark could figure it out ;-)
>
> Cheers,
> Bob
>
>
> On Mon, Feb 2, 2009 at 2:28 AM, Elliott Sprehn <espr...@gmail.com> wrote:
> >
> > We do a lot of dynamic SQL generation and ran into some really odd
> > behavior with TQL parameters without the type attribute because the
> > value being passed in isn't converted to the right type by the JDBC
> > driver.
> >
> > This is expected behavior with the current implementation.
> >
> > I've resorted to getting the metadata of the object in the query and
> > using getPropertyByName().getType(), but this is rather long winded.
> >
> > I propose allowing the type attribute of the setParam() function to
> > accept a dotted path to a property.
> >
> > query.setParam(":1",now(),"attendee.Attendee.registrationDate")
> >
> > At the very least this can be implemented in the t:queryparam tag
> > without changing the inside of Transfer at all and would make dynamic
> > TQL much easier, especially when refactoring and possibly changing
> > property types (ex. from numeric to date).
> >
> > >
> >
>
>
>
> --
> Bob Silverberg
> www.silverwareconsulting.com
>
> >
>


-- 
E: mark.man...@gmail.com
W: www.compoundtheory.com

--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer

You received this message because you are subscribed to the Google Groups 
"transfer-dev" group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to 
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to