From dev-return-30541-archive-asf-public=cust-asf.ponee.io@geode.apache.org Tue Jan 15 19:49:23 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 2EEBE180609 for ; Tue, 15 Jan 2019 19:49:23 +0100 (CET) Received: (qmail 73699 invoked by uid 500); 15 Jan 2019 18:49:22 -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 73687 invoked by uid 99); 15 Jan 2019 18:49:21 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2019 18:49:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 07C0BC030B for ; Tue, 15 Jan 2019 18:49:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 44ymGj61HVpX for ; Tue, 15 Jan 2019 18:49:18 +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 7AA4E5F418 for ; Tue, 15 Jan 2019 18:49:18 +0000 (UTC) Received: from pps.filterd (m0114581.ppops.net [127.0.0.1]) by mx0a-00296801.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0FIkbAZ009956 for ; Tue, 15 Jan 2019 18:49:17 GMT Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by mx0a-00296801.pphosted.com with ESMTP id 2pybmw2mwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 15 Jan 2019 18:49:17 +0000 Received: by mail-lj1-f199.google.com with SMTP id 18-v6so941096ljn.8 for ; Tue, 15 Jan 2019 10:49:16 -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=h8yFDOlQYrv+JsAeEm3OlsWiDBzra35p1LbfQN7TFmA=; b=GpCVdONDEu6bg4zyXFchLnE5VGvgnRUNUQKTlb1/fAKQE6XhgjUD4uJF4aOoejdj0M irrTfQ0fLCgSyFvGyrZJpFeHEkymLt0JHfdcPEKZP1vqk9IWm/E4n8kBUFOhEc257V44 TpnbMvflPkygvDp4NBjE8AJ3ffkIw/Ullmi8Y/PCs104cdmMIVnNyw8UfDJFiLQFb+P3 46xji7UvaUPoRTJvNYnGvmbbhyqw3LhKAxRXbB0/0Zu9iKCkt2S17++Dlnh8yDEz9yr1 3gTy1BhVm+KmyEX3jW6PsYn+T6jptLyag9Caj8VaA7y9Spr9yLoseQ1XvWfdRCjkMiqe EJXQ== X-Gm-Message-State: AJcUukcaOW0Q7GNcZqPO30ihACTLBC4zJXuwzmGE8TkIOUnR/qtmdnUj W9BVIdA72qTPy67mTYcwjG6y6302lkKnRt1PMTEsKKPWCmQ+wRMSdD6QLfTU6/sNGG4np5gEjWE muiavq3ugBOh2WO4tc5C8DAnLJj3U3shm5zJWEgaILfEA5tt26aJWvCo= X-Received: by 2002:a2e:5054:: with SMTP id v20-v6mr3851928ljd.45.1547578154279; Tue, 15 Jan 2019 10:49:14 -0800 (PST) X-Google-Smtp-Source: ALg8bN4Qlk26pwIQkmJ6hQ1lR4zctLFlb9HAzU6M+wJ1yo0F4dptkNkI0DpSydW2G0ldf41qgDOOt4RHq+MngowHnn8= X-Received: by 2002:a2e:5054:: with SMTP id v20-v6mr3851902ljd.45.1547578153869; Tue, 15 Jan 2019 10:49:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Darrel Schneider Date: Tue, 15 Jan 2019 10:49:02 -0800 Message-ID: Subject: Re: [Proposal] adding a new type of PdxInstance To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="0000000000001fbaed057f839e9c" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-15_06:,, 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-1901150151 --0000000000001fbaed057f839e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 if those are going to be done based on a sequence of serialized bytes then you really need to understand your serialization code and make sure that "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 value in > serialized form and in others we don't. The point is, why limit to 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 i= s > > that in some members the key may be seen as a PdxInstance and in 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 about 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 t= o > 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 als= o > be > > used in other contexts when you just want some structured data with wel= l > > defined fields but never need to deserialize that data to a domain clas= s. > > > > 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 meth= od > > that creates a PdxInstanceFactory named "forcePDXEveryWhere". Internall= y > 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 y= ou > > 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? > > > --0000000000001fbaed057f839e9c--