Why are services described in docs and in gocb different?

#1

The docs describe these services:

  • Data : Supports the storing, setting, and retrieving of data-items, specified by key.
  • Query : Parses queries specified in the N1QL query-language, executes the queries, and returns results. The Query Service interacts with both the Data and Index services.
  • Index : Creates indexes, for use by the Query and Analytics services.
  • Search : Create indexes specially purposed for Full Text Search . This supports language-aware searching; allowing users to search for, say, the word beauties , and additionally obtain results for beauty and beautiful .
  • Analytics : Supports join, set, aggregation, and grouping operations; which are expected to be large, long-running, and highly consumptive of memory and CPU resources.
  • Eventing : Supports near real-time handling of changes to data: code can be executed both in response to document-mutations, and as scheduled by timers

The GoSDK service constant is as such:

const (
	// MemdService represents a memcached service.
	MemdService = ServiceType(gocbcore.MemdService)

	// MgmtService represents a management service (typically ns_server).
	MgmtService = ServiceType(gocbcore.MgmtService)

	// CapiService represents a CouchAPI service (typically for views).
	CapiService = ServiceType(gocbcore.CapiService)

	// N1qlService represents a N1QL service (typically for query).
	N1qlService = ServiceType(gocbcore.N1qlService)

	// FtsService represents a full-text-search service.
	FtsService = ServiceType(gocbcore.FtsService)

	// CbasService represents an analytics service.
	CbasService = ServiceType(gocbcore.CbasService)
)

A bit confused

#2

Hi @ajpikul,

Adding these services to gocb predates me but I could guess that differences are largely down to naming evolving and maturing over time. This means that the names in docs might change slightly but in gocb we can’t do that without making breaking changes. At the moment I believe that we only expose the ServiceType for use with the Ping API too, so we just “ping” a relevant endpoint to ensure it responds in time (also bear in mind this API is marked experimental at the moment), so that considered things roughly equate as:
Data - MemdService
Index - MgmtService
Query - N1qlService
Search - FTSService
Analytics - CbasService

We don’t have an Eventing service yet and the CapiService is for things like views, which isn’t supported by Ping anyway.

1 Like
#3

Thank you! Just wondering because I’m using it for health-checking service dependencies and had to decide which ones I should ping. It seems like the first three are prerequisite and the last two are optional.