Thank you Jason.
I have one more question related to this.
I have two options / object structures for storing and retrieving objects.
First one .
Storing objects like : {key :"ConstantString_randomString", List
objects}
and then use queries with like "ConstantString_%" where function index is
Hi there Geode dev's.
I'm starting to notice more and more discussions about proposed features
or JIRA tickets, where imo, core Geode tenets are being violated.
Initially I thought that Geode must be lacking core tenets, to guide our
decisions. BUT then I noticed that we do state the on the ho
There is only 1 thing I would add to this list is, above all others...
1. Correctness
Of course, this ought to go without saying, but do the right thing, always,
even at the peril of all the other things combined. It is all too easy to
focus on the shinny things (e.g. performance, latency, high
1 more thing...
Yes, CORRECTNESS is not going to be the glamorous thing. You cannot market
it because it is not sexy, not cool, it is simply expected as the bar to
entry. No one notices when the system just works as it should. You will
not get compliments, no thank you's. It's just "Business A
== should in theory be faster. The compiled like eventually boils down to
a >= query but it takes a few steps to get there.
If I understand correctly. the second approach would be indexed on a string
field and the query would look similar to "select * from /region where
stringField = 'ABC'" If t
Can you provide examples of discussion you believe violate there tenants?
> On Nov 28, 2018, at 11:12 AM, Udo Kohlmeyer wrote:
>
> Hi there Geode dev's.
>
> I'm starting to notice more and more discussions about proposed features or
> JIRA tickets, where imo, core Geode tenets are being violat
I think the most recent conversations that come to mind are:
* DLQ for WAN Gateways
* A current discussion about a bug regarding Tombstones, Entry removal
and client/server inconsistencies.
All I am pointing out is, if one is working on any feature or bug and
there is any doubt about direc
John, I 100% agree with your statements!
We should add that to the list as well...
On 11/28/18 11:54, John Blum wrote:
1 more thing...
Yes, CORRECTNESS is not going to be the glamorous thing. You cannot market
it because it is not sexy, not cool, it is simply expected as the bar to
entry. No
TypedJson is our own implementation of serializing objects into json
strings. It is used to produce a json string when user executes a query
though jmx (DistributedSystemMbean.querydata call). Due to is usage of
org.json and some usage of it causes StackOverFlow that kills the server,
we would like
All,
We started iterating on a solution for supporting Java modules based
applications linking to Geode as a module dependency. Now before you go, "but
why didn’t you do X?”, let’s set some ground rules here. The initial goal was
to get *a* solution, not the best solution, for linking and using
I like the exploratory approach and focusing on the application developer UX.
I’m curious to see how the next experiments go. I’d prefer to align our grade
submodules with java module definitions (e.g. geode-core becomes a module).
Are the fat jar module definitions solely for the client? If
11 matches
Mail list logo
