Forum https://discourse.hanamirb.org – Code of Conduct http://hanamirb.org/community/#code-of-conduct
hanami-controller and hanami-router. I'm trying to wire up controllers to use hanami-view but with no luck yet. There isn't much (or anything at all) in the docs about wiring the controller and view together when used as standalone gems. I get the view to render by calling it directly from the controller with self.body = Views::Users::Index.render ... but that is not what I'm after.
Hanami 2 work is ongoing, but nothing really suitable for anybody but early adopters. You'll be prone to some change that might be unavoidable.
Hanami 1 works but the model layer is changing in Hanami 2, so we're not sure how backwards compatibility might look. Folder structure is changing likely as well.
hanami-api on it's own. It's built on top of other components that Hanami 2 are already using (hanami-controller and hanami-router). The small DSL you get would likely be better with the full template style. Your decision obviously.
Hi guys, I have a question about the parameter validations in the controllers. We want to validate some Array type parameters, but the error message we get is not the desired one. We invoke the validation in the param block with: required(:channels).filled { each { included_in?(Offer::CHANNELS) } }
The problem comes from the params.error_messages method. It maps the error messages in a way, that in the end, the output comes without the name of the field, and only the index where the validation error occured: "message": "0 must be one of: online, offline, phone" and it does not state that this error belongs to the channel field. My desired output would be something that includes the field name also, not just the index.
So my question is, that is this the intended way for this method to work? We did a workaround with a custom predicate and error message, but I am curious, how would you solve this? What would be the hanami way of doing this?
Thanks in advance!
hanami-validations are you using?
dry-validation and dry-schema.
rack implementation is supported ?at least from what I know,
puma is supported, but could I use any async server like https://github.com/socketry/falcon
Hi, can someone help me understand the following conundrum:
I've changed this
def find_by_segment_match(source_text_for_lookup, source_lang, sim_score)
aggregate(:translation_records)
.where(language_id: source_lang)
.where { similarity(:content, source_text_for_lookup) > sim_score/100.00 }
.select_append { float::similarity(:content, source_text_for_lookup).as(:similarity) }
.order { similarity(:content, source_text_for_lookup).desc }
endto this
def find_by_segment_match1(source_text_for_lookup, source_lang, sim_score)
segments
.where(language_id: source_lang)
.where { similarity(:content, source_text_for_lookup) > sim_score/100.00 }
.select_append { float::similarity(:content, source_text_for_lookup).as(:similarity) }
.order { similarity(:content, source_text_for_lookup).desc }
endAnd now I don't get back the similarity function result.
This is in the segment repository where I've removed translation_record aggregation since it didn't work well on the current model version.
select_append is not returned.
# config/environment.rb
# ...
DWH = Sequel.connect(ENV['DWH'], :loggers => [Logger.new($stdout)])
#...# config/puma.rb
require_relative './environment'
workers 5
threads_count = 1
threads threads_count, threads_count
daemonize true
stdout_redirect '/home/user/app/shared/log/puma.stdout.log', '/home/user/app/shared/log/puma.stderr.log', true
pidfile "/home/user/app/shared/pids/puma.pid"
preload_app!
rackup DefaultRackup
port 2300
environment 'production'
before_fork do
DWH.disconnect
end
on_worker_boot do
Hanami.boot
endDatabaseDisconnectError-issue https://stackoverflow.com/questions/66443278/ocurrence-of-sequeldatabasedisconnecterror-at-puma-worker-even-though-the-db/66452766#66452766Somebody still possibly has a solution trial...
select_append from a few posts up. I couldn't get it to work, i.e. to append to the Segment record. My best guess is the limitation of mapping to the entity. So for now I have a rather ugly workaround where I still do aggregate but overwrite the translation_recordsarray later on. I'll wait for higher versions of Hanami model to refactor this.
