apache / cassandra-gocql-driver

GoCQL Driver for Apache Cassandra®
https://cassandra.apache.org/
Apache License 2.0
2.59k stars 621 forks source link

CASSGO-29 refactor packages to separate frontend api to backend internal api #465

Open Zariel opened 9 years ago

Zariel commented 9 years ago

Currently everything exists within the gocql package, as the driver functionality expands the package gets more and more complicated.

We should maintain the current API in the gocql package, but move much of the internal things out into sub packages.

Zariel commented 9 years ago

A good starting point would be to move the unexported marshalling code into an internal package and export just the Marshall / Unmarshall functions from the gocql package

OleksiienkoMykyta commented 1 week ago

@joao-r-reis I can handle it, but there are a few tricky moments:

  1. It would be nice to split gocql by multiple packages, but it will cause issues with backward compatibility, we can use type aliases like in the following PR or merge it to gocql v2.
  2. Also, we should decide what exactly we want to move to separate Go packages and what kind of architecture we want. Something could be changed during implementation, but there is a lot of work, so it would be great to have more details on this issue. In my opinion, it would be better to split the project into small packages like the marshal, framer, session, etc. to provide more flexibility and scalability, also it will make it easier to navigate through the project.

What do you think?

joao-r-reis commented 1 week ago

I think the project is not that big that it needs a lot of packages, the main purpose of this ticket should be to at least keep the public API stuff on the current gocql package and move everything else to an internal package in ./internal/.... After this then we can think of splitting the internal package into multiple internal packages but I'd focus on just having the gocql package for the public API and a single internal package to start with.

joao-r-reis commented 1 week ago

Maybe we could add an internal protocol package for framer and marshal code right away too (maybe a "native protocol package")

joao-r-reis commented 1 week ago

Oh keep in mind that since this will change a lot of files it will be hard to keep the PR in sync with all other PRs that are waiting to be merged atm. There will be a lot of work involved in resolving git conflicts.

OleksiienkoMykyta commented 1 week ago

Ok, I'll start with the framer, and then we can check it as an example

joao-r-reis commented 1 week ago

Ok, I'll start with the framer, and then we can check it as an example

It might make more sense to group framer and native protocol stuff in a single package but I'm not sure