我有存储创建临时表的过程.我想再执行一个与这些临时表连接的查询.
问题是,使用Golang的数据库/ sql设计,确保为后续查询获得相同连接的唯一方法是创建事务.
如果为了访问临时表而将大部分SELECT包装在事务中,我是否会遇到麻烦？我知道我将失去一些性能/可伸缩性,因为我将保留池中的连接,而不是允许它们在查询之间返回.但我想知道我是否会开始看到此策略的锁定或其他严重问题.
我需要这样做的原因是因为我的许多表的MySQL执行计划非常差(我在大表中进行多次连接).我想执行一些中间查询并将结果存储在临时表中以避免此问题.
我遇到了一个常见的模式,我有一个接受用户输入的函数,并返回一个成功的输出值或错误.但它可以返回不同类型的错误,其中一些是用户输入错误的结果,另一些是内部错误导致的错误(例如,DB不可用).
我的函数有如下签名:
// ProcessInput takes a user-input string and returns a processed value
func ProcessInput(input string) (ProcessedValue, error, error) {}
如果没有遇到错误,则第一个返回值是有意义的(不是nil),如果用户输入验证失败,则第二个返回值是错误,如果发生意外的内部错误,则第三个返回值是错误.
这样工作正常,但感觉不是很干净,从签名看不同的错误是不明显的.我考虑过命名错误返回,但我不喜欢命名返回参数的副作用.
我还能申请更清洁的其他模式吗？我是否应该有一个错误返回并按呼叫者方面的类型区分？
我正在使用Goji(https://github.com/zenazn/goji),并希望定义具有自己的中间件的路由组.例如,下面的所有路径/company都应使用LDAP身份验证,并定义中间件来执行此操作.所有路径都/external使用不同类型的身份验证,因此它们具有不同的中间件定义.但这是在同一端口上提供的单个应用程序,因此我不想完全创建单独的Web服务 - 只是路径(和某些特定路由)可能使用不同的中间件.
我在Goji上看到的所有示例都是针对所有路由使用一组中间件,所以我不确定如何以干净的方式完成此任务.另外,如果我可以为路由组中的所有路由指定基本路径,那将会很好,类似于我在其他路由框架中看到的路径.
我是否在Goji库(或扩展名为net/http)中缺少此功能,这允许我将路由组合在一起并让每个组使用自己的中间件堆栈？
我想要实现的是这样的(psedocode):
// Use an LDAP authenticator for:
// GET /company/employees
// and
// POST /company/records
companyGroup = &RouteGroup{"basePath": "/company"}
companyGroup.Use(LDAPAuthenticator)
companyGroup.Add(goji.Get("/employees", Employees.ListAll))
companyGroup.Add(goji.Post("/records", Records.Create))
// Use a special external user authenticator for: GET /external/products
externalGroup = &RouteGroup{"basePath": "/external"}
externalGroup.Use(ExternalUserAuthenticator)
externalGroup.Add(goji.Get("/products", Products.ListAll))
我正在使用具有非常复杂的访问控制规则的系统中的API.通常,需要复杂的SQL查询来确定用户是否具有对特定资源的读取或写入访问权限.这会在我们的客户端应用程序中造成很多复杂性和冗余,因为他们必须知道所有这些规则,以确定是否为每个对象呈现用户CRUD选项.
我的目标是减少客户端的大部分复杂性,并容纳API中的所有复杂逻辑.这样,在确保UI仅向用户提供有效选项时,针对我们的API编写的新客户端应用程序可以避免重新实现复杂的访问规则逻辑.
我不确定最好的办法是什么.我正在考虑两种不同的选择,但我不知道是否有更好或更标准的方法向API的调用者公开通用访问信息.
当调用者对资源实体或它们的集合发出GET请求时,每个返回的实体都将返回一个_allowed_actions附加的字段,该字段是允许调用者在该实体上执行的一系列操作.例如,请求Listing对象可能导致以下响应.
GET/listing/5
{
"id": 5,
"address": "123 Foo Street",
"city": "New York",
"state": "New York",
"price": 457000,
"status": "pending",
"_allowed_actions": ["READ", "UPDATE", "DELETE"]
}
仍然不确定如何与客户关联他们是否有权使用此方法创建资源实体的实例,但客户可能只需要保持对权限结构的充分理解以自行确定.围绕创建实例的访问规则通常不如READ/UPDATE/DELETE访问规则复杂,因此看起来并不太糟糕.
创建一个元API,客户端可以向其发出请求,以确定它们可以对每个资源执行哪些操作.例如,检查客户端可以对列表执行的操作:
GET/access-query/listing/5
{
"allowed_actions": ["READ", "UPDATE","DELETE"]
}
并检查一般的列表允许的选项,包括CREATE:
GET/access-query/listing
{
"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}
这种方法的好处是它允许呼叫者以通用方式完全理解他们可以对每个资源做什么.这样,客户端就不必理解为了创建列表,需要"create_listing"权限和非试用用户状态.他们可以提前查询此信息.
这种方法的缺点是它增加了请求量.他们现在必须查询一次以确定他们可以做什么以及第二次执行此操作,而不是要求客户端了解权限逻辑.
我并不特别关心这些方法中的任何一种,但我现在只能提出这些方法.有没有更好的方法来解决这个问题？
我有一个Go流程,通过管道接受输入.
tail -f something.foo | 去运行myprog.go
由于stdin是管道的输出,我找不到在myprog.go中读取键盘输入的方法.这可能吗？
我考虑在myprog.go中执行tail命令,但是我想避免在myprog.go崩溃并且无法终止另一个进程时创建另一个进程.