Unless of course, I am missing something On Fri, Jun 12, 2015 at 2:51 PM, Atri Sharma <[email protected]> wrote:
> A problem I see with introducing custom aggregate function is problem of > serialization/deserialization of transition states (assuming aggregate > execution infrastructure looks like transition function -> transval -> > final function -> output). If we allow custom aggregate functions we may > also need to allow transition states to be "blackbox" for the system since > we are not aware of the transition states that might be needed by custom > aggregate logic for its operation. I see two solutions to this problem: > > 1) Allow only specific transition state types to be allowed (Bad idea. It > restricts the flexibility of custom aggregates that can be written.) > 2) Make an umbrella type for all blackbox transition states. We can ensure > that for that type, serialization and deserialization functions are > provided by user. > > Thoughts? > > On Fri, Jun 12, 2015 at 2:14 PM, Yakov Zhdanov <[email protected]> > wrote: > >> I am crossposting this to dev list as well. >> >> So, is there a way to introduce custom aggregate function? I assume no. >> >> But even if we have such ability, writing and plugging such custom >> function >> seem to be much harder to do than direct reducer/transformer from java >> code. However, this is not very common usecase in SQL, I think. >> >> I think it would be very nice to support custom aggregate functions. As >> far >> as java-reducers - this is not very intuitive and I would skip adding them >> back if custom aggregate is possible. >> >> Sergi, Alex, can you please share your opinions? >> >> --Yakov >> >> 2015-06-09 22:21 GMT+03:00 Dmitriy Setrakyan <[email protected]>: >> >> > Also, if you need to return only a portion of the object (just a few >> > fields), you can use SqlFieldsQuery and select only specific fields: >> > >> > select a, b, c from Person... >> > >> > D. >> > >> > On Tue, Jun 9, 2015 at 1:20 PM, fluffy <[email protected]> wrote: >> > >> >> Using GridGain, I used to be able to associate a GridClosure method >> with a >> >> GridCacheQuery. You could simply pass this Closure method into the >> >> GridCacheQuery.execute() function and it would perform a function on >> each >> >> cache element that matched the SQL query. >> >> >> >> This basically consolidated a number of tasks: >> >> >> >> - Instead of receiving entire objects from a query, a much smaller >> result >> >> value was sent back to the node that initiated the query >> >> - Allowed for the specification of some functionality within each Cache >> >> Element rather than being a fairly dull data store >> >> - Allowed for distributed processing of Cache Element information on >> the >> >> node that each valid element existed before being aggregated/merged on >> the >> >> calling node >> >> >> >> I do not see this functionality as having been ported to the Ignite >> >> release. >> >> At least not directly. Is there a way to do this in the current Ignite >> >> version? >> >> >> >> I was looking at either a ScanQuery or using the AffinityRun methods, >> but >> >> the later don't seem to allow me to perform an SQL query first to limit >> >> the >> >> Cache Elements.... >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> http://apache-ignite-users.70518.x6.nabble.com/Closure-method-on-a-Cache-Query-tp456.html >> >> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >> >> >> > >> > >> > > > > -- > Regards, > > Atri > *l'apprenant* > -- Regards, Atri *l'apprenant*
