Objects in QoQ group by throwing an error

I can’t migrate an app which uses QoQ until the bug relating to objects in QoQ group by throwing an error is addressed

https://luceeserver.atlassian.net/browse/LDEV-691

also, any plans to finally fix SSL cert support, basic things like fetching a file from wikipedia don’t even work OOTB?

Understand it’s a compatibility issue, Zac, but is it really a bug? Why would you expect a query cell to contain a native CFML struct which I don’t think any database would accept without serializing it first (which is what the error is suggesting you do)?

well, what does count(*) mean in this context, my understanding is that it means just count the number of rows.

why is the obj column being evaluated toString() by this query, it’s not referenced? Does it mean toString() is being called on column, every row, which is completely unnecessary. there could be a performance improvement for count(*) against larger result sets?

1 Like

That’s a valid point about the impementation and possible performance issues, Zac, but still - why would you want/need to store a native cfml struct inside a query cell without serializing it?

Perhaps the data will never touch a DB and you just want to be able to use QoQ functionality on it, in which case fair enough.

But if you do serialize it as Lucee expects, the QoQ works, so you do have a “workaround” (just replace duplicate( obj ) with serialize( obj ) and then use evaluate( obj ) when you want to restore the native CFML structs).

I’d prefer these next sprints to prioritize “blockers” with no workaround, such as this one: https://luceeserver.atlassian.net/browse/LDEV-1229

Did you try count(mod) instead of count(*), or does it still fail regardless of what you select on? It does seem like a bug that should be fixed…

A query is a data structure, and there’s nothing wrong with putting struct values into queries normally. Serializing and deserializing may end up being extra work that isn’t needed :slight_smile:

count(mod) still crashes

1 Like

Yes, on reflection that’s quite true Justin.

anyone know why this split topic doesn’t appear on the front page?

Just a quick note to let you all know I’ve got one eye on this ticket (691). It’s being investigated, so let’s see what that yields in terms of repeatability, priority, etc. As always, for everyone affected by this, please upvote the ticket. That’s one of the clearest signs we can get from our community about urgency.