From dev-return-30558-archive-asf-public=cust-asf.ponee.io@geode.apache.org Tue Jan 15 23:29:26 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4F41A180609 for ; Tue, 15 Jan 2019 23:29:26 +0100 (CET) Received: (qmail 29501 invoked by uid 500); 15 Jan 2019 22:29:25 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 29485 invoked by uid 99); 15 Jan 2019 22:29:24 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2019 22:29:24 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4E89DC0BE0 for ; Tue, 15 Jan 2019 22:29:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id vBVtsw0VzTnC for ; Tue, 15 Jan 2019 22:29:22 +0000 (UTC) Received: from mx0a-00296801.pphosted.com (mx0a-00296801.pphosted.com [148.163.150.38]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id F379C5F205 for ; Tue, 15 Jan 2019 22:29:21 +0000 (UTC) Received: from pps.filterd (m0114582.ppops.net [127.0.0.1]) by mx0a-00296801.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0FMLaSx008510 for ; Tue, 15 Jan 2019 22:29:21 GMT Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by mx0a-00296801.pphosted.com with ESMTP id 2pyaew2wuq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 15 Jan 2019 22:29:20 +0000 Received: by mail-lj1-f198.google.com with SMTP id t22-v6so1088067lji.14 for ; Tue, 15 Jan 2019 14:29:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qsNxeyhfp5UmMKUHnFmy14sjxLvexfcyd3qDRLn6zMk=; b=EJR7v0kIb6uXEDFcOEHwuTl2ENNVi5HvzypUbgLCWBPoy3CVQBO0rveN746h85F0nT O5fHxOkYAtJyoaeZv8E8AJtYk2PkJxPHH2d1sRHivLR3oO3z0x7Jjv0eNbIE+E5Rltqv MyDNgk/TTH5A934A1iXJ0hLpQz8yW6qp3dZoO4mueHyI4CJ7sfUfJRHLIWlRqmjBhlQ6 QqCiqLIc95zJfQnA2/ZeZKFuCb021iCo2cbNiKG6wuk154kEGZ5cWj3lDeHJzN3q7UI3 XurZbIq7AKK3ozeOrnrP+J/5VIjwGLo8KcFPborHORobo9BGWHTQqsWoCi7yYR1mZhxU 6EtQ== X-Gm-Message-State: AJcUukctKjnmPjrlZJsFKi3eCTA8JAhJPtFKr137W41UkZIJQ77mx8dq t1L6H3Ab5ohckXbaa76tl4dT+I8XTtA/drSjv7S8Ic+DkskOtCORjvwzgsjerWlTteydW680gNu lwjb/aVV7mhGxhIqc5i8/udxqKFQJUMduhMs19NMp6xapAv4UBDePyOg= X-Received: by 2002:a19:ced3:: with SMTP id e202mr4417308lfg.13.1547591357759; Tue, 15 Jan 2019 14:29:17 -0800 (PST) X-Google-Smtp-Source: ALg8bN6FoitXwn6Y34+RUQuH401PXQsyOMvuOib6lYftlwcVc2tbY2fLboDkb6t9itCBkXyiM++6HbMqmtPQtmrJW2U= X-Received: by 2002:a19:ced3:: with SMTP id e202mr4417293lfg.13.1547591357353; Tue, 15 Jan 2019 14:29:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Darrel Schneider Date: Tue, 15 Jan 2019 14:29:06 -0800 Message-ID: Subject: Re: [Proposal] adding a new type of PdxInstance To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="0000000000001cec2c057f86b1de" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-15_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901150177 --0000000000001cec2c057f86b1de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dan, we still want a "class name" but it no longer has to be an actual name of a java class. It can now be just a logical "type name". For two PdxInstances to be equal they need to have the same class name. So we really do just want a flag that says: never deserialize this PdxInstance. Anil suggested a "setDeserializable(boolean)" and "isDeserializable()" in place of stable. On Tue, Jan 15, 2019 at 1:21 PM Dan Smith wrote: > If I understand this right, you are talking about a way to create a > PdxInstance that has no corresponding java class. How about just a > RegionService.createPdxInstanceFactory() method that doesn't take a > classname, and therefore has no corresponding java class? It seems a > PdxInstances without a class is a more fundamental PdxInstance. A > PdxInstance with a java classname on it is just an extension of the > classless version. > > I agree what Udo is talking about - giving the user better control of > *when* there value is deserialized to a java object - is also valuable, b= ut > a separate feature. > > -Dan > > On Tue, Jan 15, 2019 at 1:09 PM Darrel Schneider > wrote: > > > Even before the JSON pdx support we had internal support for a > PdxInstance > > that deserializes as a PdxInstance. > > This is just adding an external api for that already existing internal > > feature. So it is pretty simple to do if we can figure out how to name > it. > > > > > > On Tue, Jan 15, 2019 at 11:18 AM Galen O'Sullivan > > > wrote: > > > > > I suspect Udo is remembering something we both had to deal with, whic= h > is > > > that the lack of values to get/put PDXInstances on Regions make some > > > patterns difficult. In internal code, we have to set some thread-loca= ls > > to > > > get serialized values out, and in general, I think that setting > > > pdx-read-serialized is a violation of the contract you'd expect from > the > > > type signature of get, put, etc. Having a separate API for serialized > > > objects, and possibly region-level configuration, makes a lot more > sense. > > > You could even have the non-PDX get fail on regions that are set to > only > > > use PDX-serialized objects for everything. > > > > > > We already have something like a PdxInstance that always deserializes > to > > a > > > PdxInstance -- have a look at the __GEMFIRE_JSON mess that we use for > > JSON. > > > However you end up doing the new PDXInstance stuff, I strongly sugges= t > > > using the new solution for JSON objects. > > > > > > -Galen > > > > > > On Tue, Jan 15, 2019 at 10:49 AM Darrel Schneider < > dschneider@pivotal.io > > > > > > wrote: > > > > > > > I like the idea of adding support to the region configuration that > lets > > > > users control how it stores the data. But even if we did that, and > you > > > are > > > > correct that it would be much more work, I don't think it would > address > > > > this issue or remove the value of a PdxInstance that always > > deserializes > > > to > > > > a PdxInstance. So I'd like this proposal to stay focused on > PdxInstance > > > and > > > > not get side tracked. PdxInstances can be used outside of regions > (for > > > > example arguments to functions). > > > > > > > > I'd like to see a separate proposal about being able to configure > how a > > > > region stores its data. I could be wrong, but I think that proposal > > would > > > > focus on the values, not the keys. Storing keys as serialized data = is > > > > tricky because you need to come up with a equals and hashCode and i= f > > > those > > > > are going to be done based on a sequence of serialized bytes then y= ou > > > > really need to understand your serialization code and make sure tha= t > > > > "equal" objects always have the same serialized form. > > > > > > > > > > > > On Tue, Jan 15, 2019 at 10:38 AM Udo Kohlmeyer > wrote: > > > > > > > > > Darrel, thank you for this. > > > > > > > > > > I would like to propose a counter-proposal. > > > > > > > > > > Instead of introducing another PDXInstance type, why don't we > improve > > > > > the serialization framework itself? I know my proposal is most > likely > > > > > going to take a little more effort than adding a new type, but I > > > believe > > > > > it is less of a work around. > > > > > > > > > > MY proposal is to have the PDX serialization configuration be a > > little > > > > > more explicit. In the sense that a user can define serialization > > > details > > > > > down to the Region.Key or Region.Value level. > > > > > > > > > > Why would we possibly have a "one size fits all" approach? Could > one > > > > > have a setup where serialization configuration is stored on a per > > > region > > > > > basis. Maybe in some cases we want to deserialize the key and in > some > > > > > cases we don't want to. In some regions we want to leave the valu= e > in > > > > > serialized form and in others we don't. The point is, why limit t= o > a > > > > > single flag. > > > > > > > > > > --Udo > > > > > > > > > > On 1/15/19 10:17, Darrel Schneider wrote: > > > > > > As part of GEODE-6272 we realized we need a way to use a > > PdxInstance > > > as > > > > > key > > > > > > for a Region entry. The problem with the current PdxInstance > > behavior > > > > is > > > > > > that in some members the key may be seen as a PdxInstance and i= n > > > others > > > > > > seen as an instance of a domain class. This inconsistency can > lead > > to > > > > > > problems, in particular with partitioned regions because of the > > key's > > > > > hash > > > > > > code being used to determine the bucket. You can read more abou= t > > this > > > > > here: > > > > > > > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__geode.apache.org_d= ocs_guide_17_developing_data-5Fserialization_using-5Fpdx-5Fregion-5Fentry-5= Fkeys.html&d=3DDwIBaQ&c=3Dlnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=3De= izM8j4ZzXpU2_4tKNPdsrNNjryTeKuT6UdYhvucPpY&m=3DPba8A2NQprPqyA0LhCvz9iyCjcXg= qxkVildpFiJD6b4&s=3DblWIWwIbt5SKqKVidtZsC-cB9QK158CdEdOho54mhiM&e=3D > > > > > > > > > > > > What we want is a new type of PdxInstance that will never > > deserialize > > > > to > > > > > a > > > > > > domain class. It will always be a PdxInstance. This can safely = be > > > used > > > > > as a > > > > > > Region key since PdxInstance implements equals and hashCode. It > can > > > > also > > > > > be > > > > > > used in other contexts when you just want some structured data > with > > > > well > > > > > > defined fields but never need to deserialize that data to a > domain > > > > class. > > > > > > > > > > > > We are trying to figure out what to call this new type of > > > PdxInstance. > > > > > > Currently the pull request for GEODE-6272 has them named as > > "stable" > > > > > > because they do not change form; they are always a PdxInstance. > > > Another > > > > > > suggestion was not to name them but add a boolean parameter to > the > > > > method > > > > > > that creates a PdxInstanceFactory named "forcePDXEveryWhere". > > > > Internally > > > > > we > > > > > > have some code that has a boolean named "noDomainClass". I'd > prefer > > > we > > > > > come > > > > > > up with a name instead of using boolean parameters. In the Java > > world > > > > you > > > > > > label fields that can't change "final" and in the object world > you > > > call > > > > > > objects that can't change "immutable". Would either of these be > > > better > > > > > than > > > > > > "stable"? Any other ideas for what we could calls this new type > of > > > > > > PdxInstance? > > > > > > > > > > > > > > > > > > > > > --0000000000001cec2c057f86b1de--