Skip to content
This repository has been archived by the owner on Aug 23, 2023. It is now read-only.

move backend stores into their own package #851

Merged
merged 1 commit into from
Feb 16, 2018
Merged

Conversation

woodsaj
Copy link
Member

@woodsaj woodsaj commented Feb 14, 2018

As backend stores are pluggable, they should be in their own package.
Otherwise, their global variables get initilized when mdata is loaded.

now := uint32(time.Now().Unix())
end_month := now - (now % mdata.Month_sec)
end_month := now - (now % cassandra.Month_sec)

for _, tbl := range tables {
// actual TTL may be up to 2x what's in tablename. see mdata/store_cassandra.go for details
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think that filename in the comment needs updating now

It's safe for concurrent use by multiple goroutines and a typical usage scenario is to have one global session
object to interact with the whole Cassandra cluster.
*/
type ChunkReadRequest struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the definition of ChunkReadRequest moved here, but ChunkWriteRequest remains where it was?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chunkWriteRequests are used in the store interfaces Add method so all backend stores use them. The chunkReadRequest is a Cassandra specific implimentation detail

As backend stores are pluggable, they should be in their own package.
Otherwise, their global variables get initilized when mdata is loaded.
Copy link
Contributor

@replay replay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@woodsaj woodsaj merged commit 82d0f4d into master Feb 16, 2018
@woodsaj woodsaj deleted the moveCassandraStore branch February 16, 2018 06:01
@Dieterbe
Copy link
Contributor

what's the reason for adding the drop functionality to the mock store while also keeping devnullstore?
shouldn't we either add drop support to mock and deprecate devnull OR keep using devnullstore (and in that case, no need to add drop support to mock)

@woodsaj
Copy link
Member Author

woodsaj commented Feb 19, 2018

what's the reason for adding the drop functionality to the mock store while also keeping devnullstore

Due to circular dependencies, tests in mdata/ cant use devnullstore

Devnullstore should be kept as there are users who want to use it (only in-memory data with no backendStore). We just need config support to be able to allow them to use it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants