Hi Vaclav,
Thanks for chiming in. I am aware about audao, but did not consider it
because I wanted to keep the list of new dependencies as small as possible.
Specifically in the case of ANTLR there are backwards-incompatible changes
between 2.7 and 3.0, which would force to jarjar them into
One other thought: instead of adding a GQL interpreter, you might just
add a hook for loading a class provided by the user. That class would
implement a Filter interface with a method that takes a Configuration
and returns a Query object so in your example, mailing and timestamp
would get
Hi,
the open-source Java GQL parser (based on ANTLR) you can found here:
http://code.google.com/p/audao/wiki/ExtendedGQLParser
Vaclav
On Nov 24, 7:46 pm, Nacho Coloma icol...@gmail.com wrote:
One other thought: instead of adding a GQL interpreter, you might just
add a hook for loading a
This sounds reasonable. The challenge is mostly that finding split
points for arbitrary queries is hard at the moment. I would hold off
on doing this until after the 1.4.0 rollout is done. We have a new
feature we're rolling out (enabled by 1.4.0, although we're going to
have to do some work to
I'm not entirely sure I understand
the scope of the proposed patch. Are you thinking about adding filters
at the DatastoreRecordReader level? It's not entirely clear to me that
that provides a benefit over just applying the filter at the start of
the map() function. Totally willing to
Hi,
I'm the main author of the Java side of appengine-mapreduce. Sorry for
the delay in responding - I don't normally lurk this group, but Ikai
brought to my attention.
We're happy to accept patches. We haven't been as good as we'd have
liked about responding to them in a timely manner, since
I know, but I would prefer to discuss it first (offline is OK). I don't want
to start submitting patches without first confirming that
* I got the concepts correctly (there are a lot of possible
implementations).
* The design is coherent with whatever direction the project is taking.
* The
Is there any option to contribute to this project? I am using hacks to
do the filtering, and it seems easy to implement.
I would love to discuss things first, but appengine-mapreduce seems
like a read-only project to me. It's fine but I would like to help it
move forward.
On Nov 8, 10:11 pm,
Don't think Google would mind if you submit a patch, you have the source
code under SVN available from here
http://code.google.com/p/appengine-mapreduce/source/browse/
On Wed, Nov 10, 2010 at 6:08 PM, Nacho Coloma icol...@gmail.com wrote:
Is there any option to contribute to this project? I am
Ikai,
Are there any plans to support filter functionality in the future? I
have a similar situation where I want to iterate over a collection
that is big enough to be used by the mapper framework, but much
smaller than the actual collection size of all entities of that kind.
Brad
On Nov 8,
There was talk about supporting it, but the priority is getting out the
shuffle/reduce steps first.
appengine-mapreduce is an open source project. You can probably just
edit/subclass DatastoreInputFormat.java and add the filter functionality:
11 matches
Mail list logo
