2 回答
TA贡献1818条经验 获得超7个赞
我不熟悉 gocql 库,但听起来您可能会遇到不重新准备语句和CASSANDRA-7910 的组合。
每当一个请求准备好时(比如在 Select * from ___ where date in ? cassandra,您知道可以查找哪些列。看起来 gocql 有一个称为Automatic query preparation
可能将您的请求视为准备好的语句的功能。
当您更改表时,准备好的语句不会在您的客户端更新,因此真正解决此问题的唯一方法是重新准备您的语句(不确定您是否具有来自 gocql 的控制级别)。但是,这仍然不起作用,因为 cassandra ( CASSANDRA-7910 ) 中存在一个错误,它不返回新列,因为它本身正在缓存准备好的语句,并且在架构更改时不会使其无效。此问题已在 2.1.3(即将推出)中修复,可能值得针对 git 中的 cassandra-2.1 分支尝试此操作,以查看是否能解决您的问题。
在您的应用程序运行时更改您的架构并不是一种异常模式,因此这是一个应该有效的场景,但不幸的是没有。我会研究一下是否有办法在 gocql 中重新准备语句。
我看到stmtsLRU
cluster.go 中有一个var。如果你能以某种方式做到这一点,你就可以使准备好的语句无效。如果没有办法做到这一点,最好针对 gocql 提出问题,因为您可以在其他驱动程序中再次重新准备语句。我知道 java 驱动程序允许您这样做,但会给您一个警告。我想这可能是 gocql 和其他驱动程序之间的很大区别,因为在其他驱动程序中,您明确使用了准备好的语句对象,而在 gocql 中,它会在库中自动为您处理。
由于 cassandra 错误突出,我认为您应该坚持不使用准备好的语句,而是进行如下查询: SELECT * FROM api_counters WHERE date = 'total';
TA贡献1847条经验 获得超7个赞
起初,我想考虑到你告诉我的,我宁愿有时做一个SELCT column_name
,system.schema_columns
当我改变我的表时刷新它。然后我会strings.join()
在我的SELECT FROM api_counters
. 它起作用了,但如果我有 2 个不同的实例,一个会更新架构,另一个会收到 GET 请求,这个实例仍然不知道新列。
然后我重新安排了我的想法,发现显然还有另一种方法可以做到这一点,我只是针对这个模式进行了更改: CREATE TABLE stats_dev.api_counters (
date text,
description text,
all counter,
PRIMARY KEY (date, description)
);
我正在根据我期望的描述更新该字段。到现在为止还挺好。
我知道这绝对是选项 3:我的模式不是最好的。
- 2 回答
- 0 关注
- 179 浏览
添加回答
举报