Hi Nan-
If you are using SD Geode and the *Repository* abstraction, 1 thing that
will (eventually) help you is "projections".
Typically, a *Repository* is tied to a single domain object, like so...
class *LargeDomainObject* {
@Id
Long key;
byte[] data;
Collection<SomeOtherLargeDomainObject> otherLargeDomainObjects;
String name;
String author;
...
}
Then...
interface LargeDomainObjectRepository extends GemfireRepository<
*LargeDomainObject*, Long> {
...
}
With projections you could query like so...
class *LargeDomainObjectProjection* {
Long key;
String name;
String author;
...
}
Then...
interface LargeDomainObjectRepository extends
GemfireRepository<LargeDomainObject, Long> {
*LargeDomainObjectProjection* findByAuthor(String author);
}
You can achieve this with OQL now by implementing your own mapping logic in
a custom DAO. However, hopefully very soon, I intend to add "projection"
support to SDG *Repositories*, which will intelligently handle the
"mapping" for you (something to keep in mind anyway). The "projection"
infrastructure is part of SD *Commons* and is something I already
leverage/built-in OOTB for the Lucene Query support (see here
<https://docs.spring.io/spring-data/geode/docs/2.0.0.RC2/reference/html/#bootstrap:lucene>
[1]).
Follow SGF-523 <https://jira.spring.io/browse/SGF-523> - "*Add support for
Repository query projections* <https://jira.spring.io/browse/SGF-523>" [2]
for updates on my progress.
Regards,
-John
[1]
https://docs.spring.io/spring-data/geode/docs/2.0.0.RC2/reference/html/#bootstrap:lucene
[2] https://jira.spring.io/browse/SGF-523
On Wed, Aug 30, 2017 at 9:01 AM, Udo Kohlmeyer <[email protected]> wrote:
> Hi the Nan,
>
> From experience I can tell you it is better to safe the byte[] to a
> separate (colocated region). You can then have a data and properties
> region, which use the same key to store the data in both regions.
>
> The only thing you would have to manage yourself would be the CRUD
> operations for each. i.e If you insert properties you'll have to insert the
> data into the data region. If you remove/update properties you'll
> potentially have to do the same to the data region. Geode does not provide
> the mechanism to manage data splits.
>
> --Udo
>
> On 8/30/17 08:20, Lyndon Adams wrote:
>
> Yep thanks Luke.
>
> On 30 Aug 2017, at 16:12, Xu, Nan <[email protected]> wrote:
>
> “Use selective gettter methods on the wrapper object”
>
> How? Region.get() already grab the full object from network. Or something
> I am missing?
>
>
> *From:* Lyndon Adams [mailto:[email protected]
> <[email protected]>]
> *Sent:* Wednesday, August 30, 2017 10:05 AM
> *To:* [email protected]
> *Subject:* Re: Get part of the object
>
> Use selective gettter methods on the wrapper object to achieve this
> requirement.
>
>
>
> On 30 Aug 2017, at 16:03, Xu, Nan <[email protected]> wrote:
>
> Yes, but because data is big, >100K, and other is small, to save the
> bandwidth, I don’t want to get the full object back but only the other part.
>
> *From:* Dharam Thacker [mailto:[email protected]
> <[email protected]>]
> *Sent:* Wednesday, August 30, 2017 10:01 AM
> *To:* [email protected]
> *Subject:* Re: Get part of the object
>
> Region.get() is going to return you domain object.
>
> So let's say yoy have domain class with
> {
> byte[] data
> Map<String,Object> other
> }
>
>
> You can say,
> Region.get(data).getOther()
>
> Thanks,
> Dharam
>
> On Aug 30, 2017 8:18 PM, "Lyndon Adams" <[email protected]> wrote:
>
> Yes
>
>
> On 30 Aug 2017, at 15:47, Xu, Nan <[email protected]> wrote:
>
> Not sure I get it. you mean save a list, and list comprise of 2 objects --
> data and properties?
>
> *From:* Lyndon Adams [mailto:[email protected]
> <[email protected]>]
> *Sent:* Wednesday, August 30, 2017 9:45 AM
> *To:* [email protected]
> *Subject:* Re: Get part of the object
>
> Make the value a collection wrapper.
>
>
> On 30 Aug 2017, at 15:39, Xu, Nan <[email protected]> wrote:
>
> Thanks, wondering if geode can save 2 objects for a single key? So I can
> put data and other property separately. Or every key is for 1 object?
> Never use the PDX and server side function, is that mean those need to be
> deployed to the server? or there is a way to programming register the
> function to the server?
>
> Thanks,
> Nan
>
> *From:* Luke Shannon [mailto:[email protected] <[email protected]>]
> *Sent:* Tuesday, August 29, 2017 8:02 PM
> *To:* [email protected]
> *Subject:* Re: Get part of the object
>
> +1 on Mike's suggestion for the ReflectionBasedAutoSerializer
>
> To get name and author you could use OQL:
> https://gemfire.docs.pivotal.io/geode/getting_started/
> querying_quick_reference.html#reference_D5CE64F5FD6F4A808AEFB748C867189E
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gemfire.docs.pivotal.io_geode_getting-5Fstarted_querying-5Fquick-5Freference.html-23reference-5FD5CE64F5FD6F4A808AEFB748C867189E&d=DwMFaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=HB5LZowSGF4DiMmOUsCX6Q&m=8beRJvUxxhwMi53HGv0iYc9bpWOpIjRLWs6L_12UPVQ&s=XWQnjvDN7lTRBBHYWEMKtnyPfsLxW_Pq0wL1ZSMK1No&e=>
>
> On Tue, Aug 29, 2017 at 5:45 PM, Michael Stolz <[email protected]> wrote:
>
> You should probably use the PDX ReflectionBasedAutoSerializer.
> Then you can write a server-side function that you call to get just the
> fields you want and return them.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <%28631%29%20835-4771>
>
> On Tue, Aug 29, 2017 at 4:49 PM, Xu, Nan <[email protected]> wrote:
>
> Hi,
>
> I have an object comprise of
>
> MyObject{
> byte[] data;
> String name;
> String author;
> ….
> Other properties;
> }
>
> Or I can use
>
> MyObject{
> Byte[] data;
> Other allOther;
> }
>
> When I get by key, I only want to get all the properties except the data
> itself, because data could be large, is that has to be done with query?
> Not sure how the performance of query compare to region.get(key).
>
> Another question is to serialize the data. Do I need to upload the jar
> containing MyObject to geode server?
>
> Thanks,
> Nan
>
> ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
>
>
>
>
>
> --
> Luke Shannon | Platform Engineering | Pivotal
> -------------------------------------------------------------------------
>
> Mobile:416-571-9495 <%28416%29%20571-9495>
> Join the Toronto Pivotal Usergroup: http://www.meetup.
> com/Toronto-Pivotal-User-Group/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.meetup.com_Toronto-2DPivotal-2DUser-2DGroup_&d=DwMFaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=HB5LZowSGF4DiMmOUsCX6Q&m=8beRJvUxxhwMi53HGv0iYc9bpWOpIjRLWs6L_12UPVQ&s=6_3MUQQcXn4OGBkgQjyTWec_NaJU4gvp3tHRQfoV-38&e=>
> ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
>
> ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
>
>
>
> ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
>
> ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
>
>
>
--
-John
john.blum10101 (skype)
