All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
[Unreleased]
Changed
- SQL execution split out of
Client.Local. The 900-line executor — CTEs, joins, theWHEREevaluator, aggregates, casts, ordering, schema checks — isInfluxElixir.Client.Local.SQLExecutor, pure over the points it is handed through a fetch function;Client.Localkeeps storage, profiles and the InfluxQL and Flux paths. Public behaviour is unchanged. Client.Localchecks a query's column references against the first row before scanning every row's columns; the scan now runs only when a name is missing there, which is also when the error message needs the full list. Per-query fixed cost at 10k points drops from about 20 ms to under 5 ms; results are unchanged.Client.Local.SQLParsercuts a SELECT into its parts in one place. Eight regexes each found "the table after FROM" for their own dispatcher (star, column list, aggregate, DISTINCT, the clause check, the alias stripper, two helpers);split_select/1now does it once and the dispatchers work from its parts. No behaviour change; 71 lines fewer.BatchWritertests no longer inspect GenServer state to check that configuration was stored; scheduling and jitter are asserted through the observable flush instead.Client.Localsplit into three modules. The 2,470-line module now owns storage, capability checks and query execution (1,450 lines); the SQL parser isInfluxElixir.Client.Local.SQLParserand the line-protocol parser isInfluxElixir.Client.Local.LineProtocolParser, both pure. Public behaviour is unchanged; the contract suites prove it.Client.Local.query_influxql/3matches eachSHOWpattern once.- Removed the unused internal
InfluxElixir.InfluxCasecase template fromtest/support/(never shipped; no test used it). Client.Local's line-protocol splitters accumulate tokens in binaries (runtime-optimised append) instead of one list cell per byte plus a reverse and join, cutting allocations on every write to the double.
Fixed
Client.LocalrefusedLIMIT n OFFSET m, which InfluxDB 3 runs (#21). Verified against the engine:OFFSETskips rows beforeLIMITtakes them, in either order, on plain, projected, grouped andDISTINCTrows;OFFSET 0is a no-op, an offset past the end is an empty result, a negative offset is "OFFSET must be >=0" and a bare word is a schema error. All of that is now mirrored, so a paginated read can be tested against the double instead of re-implementing the offset in Elixir.Client.Localaccepted writes InfluxDB 3 rejects, and rejected one it accepts. Verified against the engine: a field written as an integer and later as a float (or tag then field, string then float, boolean then integer) is refused line by line with "invalid column type for column 'v', expected iox::column_type::field::integer, got iox::column_type::field::float";timeas a tag or field, a key used as both tag and field on one line, an integer outside int64 and an empty payload are refused; a rejected line drops only itself — the other lines are stored and the response is the partial-write JSON with one entry per bad line. The double accepted all of those (and stored every line), and refused a newline inside a quoted string value, which the engine keeps. It now keeps a per-measurement column schema ({:column, database, measurement, column}, fixed atomically by the first writer), applies a payload line by line, returns the engine's body, and drops the schema with the data when the database is deleted. Unsigned integers (7u) are accepted.Client.Local.delete_database/2kept the deleted database's points, so a re-created database was not empty. The points and schema go with it.Client.Localread a bare word insideIN (...)as a string.host IN (a, b)compared against"a"and"b"; on the engine the items are column references (v IN (1, other)works,host IN (a, b)is a schema error). Items are now parsed like every other comparand.Client.Localrefused a constant in a select list.0.0 AS volume(the #17 candle query's placeholder volume) was "unsupported column expression" in an aggregate and a schema error in a projection; the engine returns the constant on every row. Supported with an alias in every query shape; an unaliased constant is refused with the reason.DELETE ... WHERE a OR bcrashedClient.Local(:v3_enterprise) with aFunctionClauseError: the delete path still folded predicates with the helper from beforeWHEREbecame a boolean expression. It now evaluates the same expression treeSELECTdoes.CAST(col AS INTEGER)inWHEREwas rejected by 0.1.24 (#20) — and silently matched nothing in 0.1.23. The report is right that 0.1.24 refuses the orderbook depth query withClient.Local: unsupported WHERE clause: CAST(level AS INTEGER). It was never a working query on the double: 0.1.23 readCAST(level AS INTEGER)as a column named that and returned no rows for it, so tests passing against 0.1.23 were passing on an empty result.CAST(and DataFusion'scol::TYPEshorthand) now works wherever an expression is allowed —WHERE,BETWEEN,LIKE, projections, aggregates, arithmetic andORDER BY— with the engine's semantics, verified against InfluxDB 3 Core:INTEGER/INT/BIGINT,DOUBLE/FLOAT,VARCHAR/STRING/TEXT; text converts only when the whole string is a number, a float truncates to an integer, a number renders to text. A cast that cannot be performed ('abc'toINTEGER,timetoINTEGER) makes InfluxDB 3 Core drop the connection mid-response, whichClient.HTTPreports as{:error, {:connection_error, %Mint.TransportError{ reason: :closed}}}; the double reports{:error, {:connection_error, :closed}}.ORDER BYignored every term after the first inClient.Local.ORDER BY symbol DESC, levelsorted bysymbolonly. All terms apply, each with its own direction, and a term may be an expression (ORDER BY CAST(level AS INTEGER) DESC) on raw and projected rows.Client.LocalignoredGROUP BYon a plain projection andORDER BYon column-grouped aggregates, and sampled a row for an ungrouped column.SELECT host FROM p GROUP BY hostreturned every row;SELECT host, SUM(v) AS t FROM p GROUP BY host ORDER BY t DESCcame back in map order;SELECT host, MAX(v) FROM p(noGROUP BY) picked the first row's host. The engine returns one row per group, honours the ordering, and fails planning for the ungrouped column ("must appear in the GROUP BY clause or must be part of an aggregate function"); the double now does all three.Client.Localanswered queries that name a column no row has.SELECT nosuch,MAX(nosuch),WHERE nosuch = 1,GROUP BY nosuch,ORDER BY nosuchandDISTINCT nosuchare all the same 500 schema error on InfluxDB 3 ("No field named nosuch"); the double returned rows without the column, no rows, or unsorted rows depending on the clause. Every column reference in a query is now checked against the rows' columns (the check added forWHEREexpressions in 0.1.24 generalised), and an output alias remains a validORDER BYtarget.- An unbound
$placeholdermatched nothing inClient.Local; the engine fails planning ("No value found for placeholder with name $host"). The double now returns that error, so a missing binding cannot pass a test as an empty result. Client.Localrefusedmedian()andCROSS JOIN, which InfluxDB 3 runs (#19). Verified against InfluxDB 3 Core:medianreturns the middle value, or for an even count the mean of the two middle values in the column's type (two integers average with integer division: the median of 1 and 4 is 2), null over no rows, and is rejected overtime;FROM w CROSS JOIN refpairs every row with every row ofref. Both are supported, so the median-screened candle query in the issue now runs on the double with the same rows as the server. A column present on both sides of the join is refused as ambiguous, as the engine refuses the unqualified reference.Client.Localcompared a bare word inWHEREas a string.price <= med * 3comparedpricewith the text"med * 3"andhost = prodwith"prod"— both silently wrong. Either side of a comparison may now be an arithmetic expression over columns, a bare word is a column reference, and a column no row has is the engine's schema error ("No field named prod"), which is what production returns for a forgotten pair of quotes.- A
nilparam rendered as the wordnilinClient.Local; it now renders asNULL, which never matches, as the JSONnullJason sends over HTTP never matches. Client.Localreturned wrong rows forOR,NOT, parentheses and<>inWHERE, and forLIMIT 0. The clause splitter only knewAND:v > 3 OR v < 2was read as one predicate against the string"3 OR v < 2",NOT host = 'a'andv <> 1.0matched nothing, andLIMIT 0returned every row where the engine returns none.WHEREis now parsed as a boolean expression —ANDbinding tighter thanOR,NOT, parentheses, string literals opaque — and<>,[NOT] BETWEEN ... AND ...(includingtime) and[NOT] LIKE/ILIKEare supported with the engine's semantics (LIKEcase-sensitive,_one character,LIKEover a numeric column reproduces the engine's planning error).LIMIT 0returns no rows; a negative or non-numericLIMITis rejected as the engine rejects it. A malformed expression is rejected, never truncated.Client.Localcompared a string tag against a bare number by Erlang term order, sorack > 3matched every tag. The engine keeps the column as text and renders the literal (rack = 2matches"2";rack > 3does not match"10"); the double now does the same.Flight.Readerwalked empty FlatBuffer vectors at bogus indices.for i <- 0..(count - 1)withcount == 0is the descending range[0, -1]in Elixir, so a schema with no fields or a record batch with an empty buffers vector was read twice at invalid positions instead of not at all. The ranges now carry an explicit//1step, as the other comprehensions in the module already did.Client.Localrefused projected arithmetic and CTEs InfluxDB 3 runs (#18). Verified against InfluxDB 3 Core:SELECT (bid + ask) / 2 AS mid, time FROM qandWITH w AS (SELECT bid, time FROM q) SELECT DATE_BIN(INTERVAL '1 minute', w.time) AS time, MAX(w.bid) AS hi FROM w GROUP BY DATE_BIN(INTERVAL '1 minute', w.time)both return rows on the server and wereClient.Local:400s. The double now supports an arithmetic expression as a projected column (with an alias;ORDER BYmay name it), non-recursiveWITHCTEs executed in order (a later CTE or the finalSELECTreads an earlier one), table aliases (FROM q AS w,FROM q w) andalias.columnqualifiers in every clause.Client.Localsilently ignored everything after the table name.SELECT * FROM w CROSS JOIN qanswered fromwalone,... UNION SELECT ...tookUNIONas a table alias, andWHERE x IN (SELECT ...)compared against the string"SELECT ...". Joins, set operations, subqueries,HAVING,OFFSETand window functions are now rejected by name (Client.Local: unsupported SQL construct JOIN). Keywords are matched by the shape only a clause can have (OFFSET 1,OVER () and string literals are ignored, so a column namedoffsetoroverand a value such as'select from join'— both fine on the engine — still work.Client.Localreturned"time" => nilfor a row without a timestamp (a CTE that did not projecttime); the column is omitted, as everywhere else.Client.Localacceptedtimecomparands InfluxDB rejects, and silently matched nothing for ones it accepts. Verified against InfluxDB 3 Core: a bare integer (time > 1700000000) or integer param fails planning on the server ("Cannot infer common argument type for comparison operation Timestamp(ns) > Int64") and an unparseable string fails execution, while the double returned{:ok, []}for both;now() - INTERVAL '2 minutes'runs on the server but was compared as the literal string, so it too returned{:ok, []}. The parser now accepts exactly the engine's forms — quoted ISO-8601 datetimes (zoned, zone-less, fractional), quoted dates,now()offset byINTERVALterms, evaluated at query time — and rejects the rest with aClient.Local:400 that names the engine's rule.DateTimeparams rendered as~U[...]inClient.Local. Jason sends them as ISO-8601 strings over HTTP; the double now rendersDateTime,NaiveDateTimeandDateparams the same way.SELECT DISTINCT ... ORDER BYwas ignored byClient.Local: rows came back ascending whatever the direction.ORDER BYon a selected column is honoured; on any other column it is rejected with DataFusion's own message.MAX(time)/MIN(time)returned an empty row fromClient.Local(the timestamp is not a field, so the aggregate saw only nulls). They now return theDateTime, as the engine does;AVG(time),SUM(time), the statistics overtimeand arithmetic ontimeare rejected as DataFusion rejects them.Client.LocalrefusedCOUNT(DISTINCT col)andWHERE col IS [NOT] NULL, both ordinary SQL the engine runs. Both are supported.- HTTP JSON left aliased timestamp columns as strings — see the entry
above for #16/#17; this sweep's contract tests cover
MAX(time)too. BatchWriterdocumented a backpressure it could never apply. The buffer emptied on every flush, so{:error, :buffer_full}was unreachable and the tests that "proved" it forged the GenServer state. Automatic flushes now wait for an in-flight retry chain instead of opening a new chain per batch against a failing server, the buffer is bounded at10 * batch_sizewhile a chain is in flight, and the deferred buffer is flushed when the chain ends. Awrite_sync/3caller is answered by its own chain's result (the caller's reference travels with the chain; before, a later chain could answer it).BatchWritertests no longer inject:retrymessages or read GenServer state: retries are exercised through a closed port (unit) and through a Finch pool checkout timeout that resolves before the backoff fires (integration, against the real server).Client.Localrejected valid InfluxDB 3 SQL (#16, #17). Verified against InfluxDB 3 Core:STDDEV/STDDEV_SAMP/STDDEV_POP/VAR/VAR_SAMP/VAR_POP, arithmetic inside an aggregate (SUM(value * value),AVG(bid + ask), integer operands dividing as integers),selector_first|last|min|max(field, time)['value' | 'time'],SELECT DISTINCT a, b, andORDER BYa projected alias (ORDER BY bucket DESC) all work on the server and were allClient.Local:400s in the double. All are now supported with the values the engine returns;VARIANCEstays rejected because DataFusion has no such function.Client.Localreturnednilcolumns the real engine omits. InfluxDB 3 leaves a null column out of the JSON row entirely (an empty group carries onlyCOUNT: 0; a sample statistic over one row has no key). The double now omits them too, sorefute Map.has_key?(row, "avg")means the same thing on both.- HTTP JSON responses left timestamp columns other than
timeas strings. ADATE_BIN(...) AS bucketalias orselector_*(...)['time']came back as"2023-11-14T22:12:00"over HTTP but as aDateTimeover Flight and fromClient.Local.Query.ResponseParsernow decodes InfluxDB 3's zone-less timestamp rendering under any column name (zoned RFC3339 strings are still decoded only undertime/_time/_start/_stop). mix docswarned that the README'sLICENSElink had no target; the licence is now an ExDoc extra.
Added
InfluxElixir.Client.Local.check_sql/1— parse a query without running it and get the sameClient.Local:errorquery_sql/3would, so a test canflunk/1with the reason instead of being silently excluded.- Testing guide: "Checking a Query Before Running It" and "Running Against a
Real InfluxDB" (the integration tier,
INFLUX_V3_CORE_HOST/_PORT, Docker one-liners), and the new aggregate, selector and null-omission semantics with the values recorded from the engine. CLAUDE.mddescribed a/docslayout (architecture/,api/,development/, per-directory READMEs, a design template) that did not exist. The READMEs and template now exist,docs/design/README.mdindexes every design document and carries the real-engine Docker one-liners, andCLAUDE.mddescribes the actual layout.- The shipped usage rules made false claims. They told consumers to
start a Finch pool themselves (the supervisor starts one per connection),
that booleans encode as
t/f(they aretrue/false), to pass params as a keyword list (a map), and that write errors carry:retryable/:non_retryableatoms (no such atoms exist; errors are%{status, body}or{:connection_error, reason}). All three rule files rewritten against the current code. Client.HTTPraised on keyword-listparams:. Jason cannot encode the tuples, soparams: [tag: "v"]crashed the HTTP client whileClient.Localaccepted it — exactly the shape the old usage rules recommended. Both clients now accept a map or a keyword list; the contract suite proves it against the real engine.Client.Locallost concurrent writes to the same database (#15). Points were stored as one list per measurement and every write read the list, prepended and wrote it back, so parallel writers overwrote each other's inserts while all reported{:ok, :written}(159 of 480 survived in the report). The ETS layout is now one object per point, database, bucket and token, so every mutation is a single atomic insert or delete. The same change removes the quadratic copy on bulk writes: 20,000 lines took 63 s and now take well under a second. Points scan in insertion order.- The testing guide's "Key Differences" still listed
first/lastas supported aggregates and omittedDISTINCT,GROUP BY <columns>,COUNT(*)and$paramsubstitution; corrected to the current parser. - README usage example could not work. It placed
{InfluxElixir, ...}in a supervision tree (the facade has nochild_spec/1; the library is an OTP application configured viaconfig :influx_elixir, :connections), put a scheme inhost:and used the nonexistentdefault_database:key, which HTTP config validation now rejects at startup. Rewritten with a working configuration, a write/query example, the v2 options and the shipped test helper. InfluxElixir.TestHelpernow ships in the package. It was documented (CLAUDE.md, usage rules, the original design) as a helper for consuming applications' test suites, but lived undertest/support/, which is only compiled in this repository's test environment — no consumer ever received it. It is now underlib/. The usage rules also named a nonexistentsetup_local/1; the function issetup_influx/1, which passes its options straight toClient.Local.start/1. Covered by its own test module.InfluxElixir.Admin.Healthdocumented an atom-keyed%{status: "pass"}result; both clients return string keys (%{"status" => "pass"}), as the 2026-03-13 integration plan already required.
[0.1.21] - 2026-09-11
Added
- Telemetry is actually emitted.
InfluxElixir.Telemetrydocumented[:influx_elixir, :write | :query, ...]events, but nothing in the library called it.Write.Writer.write/3(henceInfluxElixir.write/3and everyBatchWriterflush) now emits the write span withdatabase,bytesandpoint_count;InfluxElixir.query_sql/3,execute_sql/3,query_influxql/3andquery_flux/3emit the query span withdatabase,transport(the client module) and, for list results,row_count.:stopmetadata carriesresult: :ok | :error. BatchWriterandWrite.Writeraccept a:clientoption to write with a specific client module instead of the configured one.InfluxElixir.Configknows:timeout,:batch_writerand:finch_name.
Fixed
Client.HTTPnever set Finch'spool_timeout(#14), so every request waited at most Finch's default 5 s to check a connection out of the pool no matter how generous:timeoutwas, and against a slow multi-node endpoint failed with a transport:timeoutat five seconds. A:pool_timeoutoption now resolves like:timeout(per-call opt → connection → 5_000) and is passed on every request, including the streaming query. Verified against InfluxDB 3 Core with a size-1 pool held by a sleeping stream — which also showed that Finch raises on a checkout timeout rather than returning an error, so the exception used to escapequery_sql/3. It is now{:error, {:connection_error, :pool_timeout}}, and the streaming query raisesInfluxElixir.StreamErrorwithreason: :pool_timeout.- Flight and HTTP now return the same
timevalues.Flight.Readerdecoded Timestamp columns to raw integers while the HTTP path yieldsDateTime; the reader now reads the ArrowTimeUnitand converts.Query.ResponseParseralso treated InfluxDB 3's zone-less JSON timestamps ("2023-11-14T22:13:20.123456789") as opaque strings becauseDateTime.from_iso8601/1rejects them; they are now parsed as UTC. Verified against InfluxDB 3 Core: identical rows on both transports. transport: :flightwas documented but ignored by the facade,Query.SQLand the usage rules; every query went over HTTP.Client.HTTP.query_sql/3now dispatches toFlight.Clientwhentransport: :flightis given, using the connection's host/token, the resolved database, andflight_port(opt, connection, or 443).params:are rejected over Flight instead of being dropped. Verified against InfluxDB 3 Core's Flight endpoint.BatchWriterretried 4xx responses. The discard clause matched{:error, {:http_error, status}}, a shape no client produces, so a rejected batch (bad line protocol, unknown database) was retried with backoff untilmax_retriesran out. It now matches the clients'%{status: 4xx}and drops the batch on the first response. The retry path is covered by a real transport error against a closed port.ConnectionSupervisorhanded the batch writer the raw config instead of the initialised connection, so abatch_writer:underClient.Localcrashed on its first flush. Covered by a supervisor-level test.ConnectionSupervisorvalidates HTTP connection config. A typo such asdefault_database:(which the facade and application docs themselves used) was silently ignored; withClient.HTTPit now fails at startup with aNimbleOptions.ValidationError.Client.Localconfigs are not validated.
Changed
timeis aDateTimeon every client and transport.Client.LocalreturnedtimeandDATE_BINbuckets as ISO 8601 strings, while the HTTP path (once its zone-less parsing was fixed, see below) and Flight returnDateTime. All three now returnDateTimewith microsecond precision, so the contract suite asserts one instant across Local, HTTP and Flight. Code that compared Local'stimeto a string must use aDateTime(six-digit sigil orDateTime.compare/2).InfluxElixir.write/3goes throughWrite.Writer, so payloads over 1 KB are gzipped likeBatchWriterflushes already were.Flight.Readerdecodes fixed-width columns with binary comprehensions (one pass, no per-element slicing) instead of indexedbinary_part/3.Client.Local.query_flux/3returns the long row shape real Flux returns: one row per field with_field/_value,_measurement,_time(aDateTime), the tags,resultand a per-seriestableindex, ordered by table then time.filter(fn: (r) => r._field == "...")is honoured. The old wide rows (%{"_measurement", "<field>" => v, "time"}) could not exercise consumer Flux handling; verified against InfluxDB 2.7.Client.HTTP.query_flux/3requests#datatypeannotations so CSV cells come back typed (double,long,unsignedLong,boolean, RFC3339 →DateTime) instead of as strings.Query.ResponseParser.coerce_types/1also converts_time,_startand_stop.parse/2returns{:error, {:unexpected_json, term}}for a JSON scalar body instead of raisingCaseClauseError.
Added
api_version: :v2 | :v3connection option (InfluxElixir.Config). Required for InfluxDB 2.x: a v2 server answers200to the v3 write path without storing anything, so writes silently vanished and malformed line protocol or an unknown bucket reported success. With:v2the client usesPOST /api/v2/write?org=&bucket=&precision=ns|us|ms|s.
Fixed
Client.HTTP.create_bucket/3works against real InfluxDB v2. It sent"orgID": "", which v2 rejects (id must have a length of 16 bytes). The org ID is now resolved from the connection's:orgname (org_id:overrides). Creating a bucket that already exists is treated as success, matchingClient.Local.Client.HTTP.delete_bucket/2accepts a bucket name. v2 deletes by ID; the name is resolved viaGET /api/v2/buckets?name=, so the same call works againstClient.Local. A 16-hex argument is used as an ID directly.- Flux CSV parsing uses NimbleCSV. The hand-rolled splitter left
\ron every last cell and header, turned the blank line between tables into a row and the next table's header into data, and broke quoted cells containing commas. All were observed against InfluxDB 2.7. LineProtocolfloats no longer lose precision.{:decimals, 17}formatting wrote1.0e-20as0.0; the shortest round-trip form is used (1.0e-20,2.5e-7), which InfluxDB 3 Core accepts and reads back exactly.Telemetry.write_start/1andquery_start/1emit wall-clocksystem_time. They emittedSystem.monotonic_time/0under that key, an arbitrary offset that is useless as a timestamp. Amonotonic_timemeasurement is emitted alongside, matching:telemetry.span/3.Flight.Client.query/3closes the gRPC channel whenDoGetfails; it was only disconnected on success.Client.Local.stop/1no longer races the owner process's ETS cleanup. Called from anon_exitafter the test process had exited, the:ets.info/1guard could pass and:ets.delete/1then raiseArgumentError, failing the test intermittently.Flight.Readerrow assembly is linear in the batch's row count. Cells were read withEnum.at/2on the column lists for every row, which made decoding a record batch quadratic; columns are now tuples read withelem/2.
Changed
Client.HTTProutes every request through onerequest/7helper that maps the status to{:ok, response}/{:error, %{status, body}}/{:error, {:connection_error, reason}}, replacing fourteen copies of the same three-clausecase. No behavioural change.
[0.1.20] - 2026-09-10
Changed
Client.Localordered aggregates now use the InfluxDB v3 SQL spelling (#13).first_value(field ORDER BY col [ASC|DESC])andlast_value(field ORDER BY col [ASC|DESC])are parsed and executed, includingGROUP BY <columns>for "latest value per group" queries. The InfluxQL-styleFIRST(field, time)/LAST(field, time)the double previously accepted are rejected: InfluxDB v3 fails planning on them (Invalid function 'last'), so accepting them let a query pass tests and 400 in production. The rejection names the v3 spelling.first_value/last_valuewithout an innerORDER BYare also rejected — DataFusion returns an arbitrary group member in that case, which the double cannot reproduce. Verified against a live InfluxDB 3 Core; the shared contract suite now passes against the real engine (it previously failed on the twoFIRST/LASTtests).Client.Localparser rejections are prefixedClient.Local:so anunsupported column expressionerror reads as a limitation of the test double rather than of InfluxDB. Plain aggregates (AVG,SUM,COUNT,MIN,MAX) now reject a second argument, as the real engine does.Client.Localreports a missing table the way the real engine does.query_sql/3on an unknown measurement returned{:error, {:table_not_found, name}}whileClient.HTTPreturns{:error, %{status: 400, body: "Error during planning: table ... not found"}}, and the streaming path mapped it to a 404. Both now produce the 400 planning error, so consumer code that matches%{status: 400}can be exercised against the double. Code matching the old tuple must be updated.
Fixed
BatchWriternow honours its:databaseoption. The value was stored in state and never forwarded to the write, so every flush landed in the connection's default database. It is now the write target unless:write_optsnames a:databaseexplicitly.Client.Local(:v2profile) accepts writes to buckets created withcreate_bucket/3. Writes only checked thedatabases:seeded at start, so a bucket created through the API returned404 database not found.Client.Localno longer re-types quoted string literals (#12). A bound string param or quoted literal such as'08338636'was parsed back throughInteger.parse, dropping the leading zero and changing the type, soWHERE repcode = $rc/IN ($rc)over zero-padded identifiers never matched while real InfluxDB v3 matched correctly. Quoted literals are now strings; only bare literals are typed. Comparing a string literal against a numeric field compares the field's text rendering, which is what DataFusion does (amount >= '1000.00'is lexical and matches500.0on the real engine too), so that footgun now fails in tests the same way it fails in production.- Linear-time accumulation in
Client.LocalWHERE parsing andFlight.Readerbatch decoding. Both appended with++inside a reduce, which is quadratic in the number of clauses / record batches. Client.Localparam substitution is whole-placeholder and single-pass.$hwas previously replaced inside$hmin, and a substituted string value containing another placeholder's name could be re-substituted.
[0.1.19] - 2026-07-08
Fixed
InfluxElixir.Client.Local.query_sql_stream/3now mirrors the HTTP client's error semantics (#11).Client.Localis the documented drop-in test double forClient.HTTP, but it still returned an empty stream on a query error or an unsupported operation whileClient.HTTPraised — so consumer code that rescuesInfluxElixir.StreamError(to avoid treating an outage as "no data") could not be exercised against the test double. It now raisesInfluxElixir.StreamErroron enumeration for both cases, matchingClient.HTTP.
Added
- Tests covering the Local
:http_status/:unsupportedstream-error paths and lazy (deferred) raising.
[0.1.18] - 2026-07-08
Fixed
query_sql_stream/3(HTTP transport) now truly streams and no longer swallows errors (#10). Previously it usedFinch.request/3, which buffered the entire response body and eagerly decoded every JSONL line before yielding — giving zero memory benefit overquery_sql/3— and it halted to an empty list on non-2xx statuses, transport errors, and unresolved databases, so every failure class looked like "zero rows". It now consumes the response withFinch.stream/5, decoding JSONL line-by-line with back-pressure (constant memory), and raises anInfluxElixir.StreamErroron a missing database, a non-success HTTP status, or a transport error when the stream is enumerated.
Added
InfluxElixir.StreamErrorexception, raised while consuming a streaming query that cannot produce rows. Carries a:kind(:no_database | :http_status | :transport | :decode | :unsupported) plus:status/:body/:reasoncontext.InfluxElixir.StreamError.stream/1builds anEnumerable.t()that defers the raise to enumeration, shared by both client implementations.- Tests covering the HTTP
:no_database/:transportpaths (real Finch pool, no mocking) andStreamErrormessage construction.
[0.1.17] - 2026-06-30
Changed
- Loosened
decimalconstraint to~> 2.0 or ~> 3.0(#9). Unblocks downstream apps from upgrading pastdecimal 2.4.1(EEF-CVE-2026-32686) and from picking upecto ~> 3.14 → ash ~> 3.29chains. Surface used (Decimal.to_string/2,%Decimal{}pattern) is stable across 2 → 3. - Loosened
grpcconstraint to~> 0.11 or ~> 1.0(#9). Unblocks downstream apps from upgrading pastgrpc 0.11.5(5 CVEs including EEF-CVE-2026-48853). - Defaulted the Flight client to the Mint gRPC adapter so the library doesn't
pull in
:gun, which becameoptionalingrpc 1.0. Mint is already available viafinch. InfluxElixir.Supervisornow skips addingGRPC.Client.Supervisoras a child whengrpc 1.0+is present (1.0 auto-starts it via its ownApplication).
Fixed
LocalClientnow supportsCOUNT(*)as a scalar and DATE_BIN-bucketed aggregate.LocalClientWHERE-clause parser now returns a 400 error for unrecognised clauses (e.g.LIKE) instead of silently matching all rows.
Added
- Regression tests for
COUNT(*), explicit column-listSELECT,INoperator narrowing, write-timestamp preservation, and silent WHERE drop.
Earlier releases
- Initial project setup with module stubs
- CI pipeline with quality checks and auto-publish to Hex.pm