From issues-return-59931-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Sun Mar 25 12:48:07 2018 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 A933418067E for ; Sun, 25 Mar 2018 12:48:06 +0200 (CEST) Received: (qmail 54599 invoked by uid 500); 25 Mar 2018 10:48:05 -0000 Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list issues@ignite.apache.org Received: (qmail 54590 invoked by uid 99); 25 Mar 2018 10:48:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Mar 2018 10:48:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 5748E1A0319 for ; Sun, 25 Mar 2018 10:48:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -101.511 X-Spam-Level: X-Spam-Status: No, score=-101.511 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 5o-VZhDqaglC for ; Sun, 25 Mar 2018 10:48:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id E2ADD5F522 for ; Sun, 25 Mar 2018 10:48:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D95D4E0186 for ; Sun, 25 Mar 2018 10:48:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id E8899214F9 for ; Sun, 25 Mar 2018 10:48:00 +0000 (UTC) Date: Sun, 25 Mar 2018 10:48:00 +0000 (UTC) From: "Alexey Kosenchuk (JIRA)" To: issues@ignite.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (IGNITE-8014) Node.js client: basic/minimal version MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/IGNITE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411853#comment-16411853 ] Alexey Kosenchuk edited comment on IGNITE-8014 at 3/25/18 10:47 AM: -------------------------------------------------------------------- [~vozerov] thanks for the comments... > 1) CacheClient - what is the purpose of setKeyType and setValueType methods from user perspective? To be able to specify the Binary Protocol types (at least, types codes) of keys and values which user plans to send/receive. Their usage is optional. When the types are not explicitly specified, the client will do automatic mapping between some of the JavaScript types and the Binary Protocol types (the mapping table is described in the header of the ObjectType class). But this mapping may not satisfy user's needs. For example, javascript has only one numeric type (number) that is standard double. But user may want to send the protocol's INT, not DOUBLE. Alternatively, every send/receive method could have the types (type codes) specification parameters. But that seems excessive. User still can send/receive data of different types to/from the same cache: a) either call setKeyType()/setValueType() methods to change the types before sending/receiving. b) or use different CacheClient instances operated with the same cache, and set different key/value types in different instances. c) or use automatic mapping only if it's enough. > 2) Errors - typically we try to have as least different error types as possible. Fully agree with this approach. > IllegalStateError, LostConnectionError - appears to be the same thing - client is not connected; I would merge it into a single entity They are different. IllegalStateError means an operation is not started at all (a request was not sent to the server). LostConnectionError means an operation was started (a request was sent to the server) but is not completed as the connection is lost (so, the response is not received). We believe it is an important difference for user. Will try to explain this more clearly in the comments. The current "failover" algorithm, suggested in other clients, makes this a bit more complicated. As a client will have not two ("connected"/"disconnected") states but three: +"connecting" state when the client tries to establish a connection with one of the endpoints from the list. Probably, IllegalStateError should be thrown in this state as well. > InternalError - I doubt user has any chance to react to this error in any way except of logging or rethrowing; I would remove it and use base IgniteClientError instead The only reason was some consistency - base class error is never thrown, only subclasses. But this is not a strong reason))) Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are unlikely can be processed by user either. Usually just logged for debug purpose. Theoretically they also can be substituted by IgniteClientError with different messages. was (Author: alexey.kosenchuk): [~vozerov] thanks for the comments... > 1) CacheClient - what is the purpose of setKeyType and setValueType methods from user perspective? To be able to specify the Binary Protocol types (at least, types codes) of keys and values which user plans to send/receive. Their usage is optional. When the types are not explicitly specified, the client will do automatic mapping between some of the JavaScript types and the Binary Protocol types (the mapping table is described in the header of the ObjectType class). But this mapping may not satisfy user's needs. For example, javascript has only one numeric type (number) that is standard double. But user may want to send the protocol's INT, not DOUBLE. Alternatively, every send/receive method could have the types (type codes) specification parameters. But that seems excessive. User still can send/receive data of different types to/from the same cache: a) either call setKeyType()/setValueType() methods to change the types before sending/receiving. b) or use different CacheClient instances operated with the same cache, and set different key/value types in different instances. c) or use automatic mapping only if it's enough. > 2) Errors - typically we try to have as least different error types as possible. Fully agree with this approach. > IllegalStateError, LostConnectionError - appears to be the same thing - client is not connected; I would merge it into a single entity They are different. IllegalStateError means an operation is not started at all (a request was not sent to the server). LostConnectionError means an operation was started (a request was sent to the server) but is not completed as the connection is lost (so, the response is not received). We believe it is an important difference for user. Will try to explain this more clearly in the comments. > InternalError - I doubt user has any chance to react to this error in any way except of logging or rethrowing; I would remove it and use base IgniteClientError instead The only reason was some consistency - base class error is never thrown, only subclasses. But this is not a strong reason))) Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are unlikely can be processed by user either. Usually just logged for debug purpose. Theoretically they also can be substituted by IgniteClientError with different messages. > Node.js client: basic/minimal version > ------------------------------------- > > Key: IGNITE-8014 > URL: https://issues.apache.org/jira/browse/IGNITE-8014 > Project: Ignite > Issue Type: Sub-task > Components: thin client > Reporter: Alexey Kosenchuk > Assignee: Alexey Kosenchuk > Priority: Major > > Develop the first basic/minimal version - for initial review/feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)