All Versions
53
Latest Version
Avg Release Cycle
6 days
Latest Release
-

Changelog History
Page 5

  • v0.2.1 Changes

    February 20, 2017
    • stop retrying a request if the failure is an internal one (driver, or driver dependencies related).
    • update the Boltex driver containing two important bug fixes: one where Boltex will fail when receiving too much data (florinpatrascu/bolt_sips/issues/16) and the other one, an improvement, make Boltex.Error.get_id/1 more resilient for new transports (details here: mschae/boltex/issues/14)
    • ๐Ÿ”„ changed the pool strategy to :fifo, and its timeout to :infinity, and let the (:gen_server) call timeout expire according to the user's :timeout configuration parameter
    • โž• added a test unit provided by @adri (thank you), for executing a Cypher query, with large set of parameters
  • v0.2.0 Changes

    • Elixir 1.4 is now required.
    • Using Boltex 0.2.0
    • ๐Ÿ›  bugfix: invalid Cypher statements will now be properly handled when the request is retried automatically
  • v0.1.11 Changes

  • v0.1.10 Changes

    February 11, 2017
    • accept Map and Struct for query parameters, transparently. Thank you [@wli0503], for the PR.
  • v0.1.9 Changes

    January 27, 2017

    ๐Ÿš€ Some of the users are encountering difficulties when trying to compile bolt_sips on Windows. This release is addressing their concern.

    Bolt.Sips will use the optional System variable: BOLT_WITH_ETLS, for depending on the ETLS package. If that variable is not defined, then Bolt.Sips will use the standard Erlang :ssl module, for the SSL/TLS protocol; the default behavior, starting with this version.

    Therefore, if you want the much faster ssl/tls support offered by ETLS, then use this: export BOLT_WITH_ETLS=true on Linux/OSX, for example. Then:

     mix deps.get
     mix test
    

    and so on.

    (Don't forget to mix deps.unlock --all, if you plan to plan to further debugging/developing w/ or w/o the BOLT_WITH_ETLS support)

    Many thanks to: Ben Wilson, for advices.

  • v0.1.8 Changes

    January 07, 2017
    • using Elixir 1.4
    • โž• add more details to the README, about the components required to build ETLS, the TCP/TLS layer
    • โž• added newer Elixirs to the Travis CI configuration file
    • minor code cleanups
  • v0.1.7 Changes

    January 02, 2017
    • ๐Ÿ”จ Connection code refactored for capturing the errors when the remote server is not responding on the first request, or if the driver is misconfigured i.e. wrong port number, bad hostname ...
    • updated the test configuration file with detailed info about the newly introduced option: :retry_linear_backoff, mostly as a reminder
  • v0.1.6 Changes

    January 01, 2017
    • we're already using configurable timeouts, when executing requests from the connection pool. But with Bolt, the initial handshake sequence (happening before sending any commands to the server) is represented by two important calls, executed in sequence: handshake and init, and they must both succeed, before sending any (Cypher) requests. You can see the details in the Bolt protocol specs. This sequence is also sensitive to latencies, such as: network latencies, busy servers, etc., and because of that we're introducing a simple support for retrying the handshake (and the subsequent requests) with a linear backoff, and try the handshake sequence (or the request) a couple of times before giving up - all these as part of the exiting pool management, of course. This retry is configurable via a new configuration parameter, the: :retry_linear_backoff, respectively. For example:
    config :bolt_sips, Bolt,
      url: "bolt://Bilbo:[email protected]:24786",
      ssl: true,
      timeout: 15_000,
      retry_linear_backoff: [delay: 150, factor: 2, tries: 3]
    

    ๐Ÿ”ง In the example above the retry will linearly increase the delay from 150ms following a Fibonacci pattern, cap the delay at 15 seconds (the value defined by the :timeout parameter) and giving up after 3 attempts. The same retry mechanism (and configuration parameters) is also honored when we send requests to the neo4j server.

  • v0.1.5 Changes

    December 30, 2016
    • ๐Ÿ‘€ as requested by many users, this version is introducing the optional url configuration parameter. If present, it will be used for extracting the host name, the port and the authentication details. Please see the README, for a couple of examples. For brevity:
    config :bolt_sips, Bolt,
      url: 'bolt://demo:[email protected]:24786',
      ssl: true
    
  • v0.1.4 Changes

    • โž• add support for connecting to Neo4j servers on encrypted sockets. Currently only TLSv1.2 is supported, using the default BoringSSL cipher; via :etls. To connect securely to a remote Neo4j server, such as the ones provided by graphenedb.com, modify your Bolt.Sips config file like this (example):
    config :bolt_sips, Bolt,
      hostname: 'bolt://hobby-blah.dbs.graphenedb.com',
      basic_auth: [username: "wow", password: "of_course_this_is_the_password"],
      port: 24786,
      pool_size: 5,
      ssl: true,
      max_overflow: 1
    

    Observe the new flag: ssl: true

    ๐Ÿšง Please note this is work in progress