Docs / ArchitectureKit / Guides / Upgrading From Version 1

Upgrading From Version 1

Version 2 of ArchitectureKit builds on version 2 of the client SDK for Go, whose types the kit takes and hands out, such as *eventsourcingdb.Client and eventsourcingdb.Event, so the two move together. Version 1 of the kit is no longer maintained.

Upgrading takes the following changes.

Changing the Module Path#

The module path ends with /v2. Import github.com/thenativeweb/architecturekit-golang/v2/architecturekit and the other packages below github.com/thenativeweb/architecturekit-golang/v2, together with github.com/thenativeweb/eventsourcingdb-client-golang/v2/eventsourcingdb:

import (
  "github.com/thenativeweb/architecturekit-golang/v2/architecturekit"
  "github.com/thenativeweb/architecturekit-golang/v2/architecturekit/httpapi"
  "github.com/thenativeweb/eventsourcingdb-client-golang/v2/eventsourcingdb"
)

The same goes for query, architecturekittest, and dbtest, such as github.com/thenativeweb/architecturekit-golang/v2/architecturekit/architecturekittest/dbtest. For what changes in the client SDK, see its notes on upgrading.

Sorting Failures by Their Code#

A failure of the database is sorted by its code (see Handling Errors). A database that offers the v2 API reports the errors of a request with the status 200, so the status no longer tells them apart. Almost every failure keeps its category, apart from these:

  • A store that has reached the capacity of its license (capacity-exceeded) belongs to ErrTransient now rather than to ErrConflict, so a store that decides again on conflicts no longer does so in vain (see Guarding Against Concurrent Changes), and the httpapi package answers it with 503 Service Unavailable rather than 409 Conflict (see Mapping Errors to Status Codes).
  • A request that did not arrive in time (408) belongs to ErrTransient now rather than to ErrPermanent.

Reporting Unknown Outcomes#

A write that was cut off after the client had connected is reported as ErrOutcomeUnknown, rather than as ErrTransient. Version 1 traced the request itself, to tell one that never left completely. Version 2 follows the client, which applies the same rule in every SDK of EventSourcingDB, and reports such a write with eventsourcingdb.ErrOutcomeUnknown (see Handling Errors).

Finding the Errors of the Client#

errors.Is finds eventsourcingdb.ErrConnectionStalled rather than eventsourcingdb.ErrHeartbeatTimeout, and the *eventsourcingdb.DBAPIError that errors.As finds has a Status, a Code, and a Description, rather than a StatusCode and a Reason:

var dbAPIError *eventsourcingdb.DBAPIError
if errors.As(err, &dbAPIError) {
  log.Println(dbAPIError.Status, dbAPIError.Code, dbAPIError.Description)
}

Handling Streams That End#

A stream that ends counts as broken off. The Err of a Reconnect and of a ProjectionStatus used to be nil then, and is an error of the category ErrTransient now, which says that the stream broke off (see Running Projections).