profile
viewpoint
Peter Leitzen splattael @gitlab Bochum, Germany https://peter.leitzen.de Passionate coder and open-source enthusiast specialised in backend development using Ruby, Crystal, Docker and Elixir.

dry-rb/dry-validation 1066

Validation library with type-safe schemas and rules

solnic/transproc 419

The project was ported to dry-rb/dry-transformer

dry-rb/dry-configurable 260

A simple mixin to make Ruby classes configurable

ruby-formatter/rufo-vim 49

Ruby format for vim via rufo

jodosha/collaborators 9

Hanami workshop

splattael/docker-phpmyadmin 8

Dockerized phpMyAdmin on Alpine

splattael/bigbrother 6

Server overseer.

splattael/dotfiles 6

Personal dotfiles

splattael/chrome-feedly-tabs 5

Open Feedly articles in new tabs.

splattael/dind-example 5

Docker in docker example

startedevansm7/vftool

started time in 18 minutes

startedanykeyh/clear

started time in an hour

startedddnexus/pagy

started time in an hour

created repositoryryanzidago/minigrep

created time in 2 hours

startedjanishar/mit-deep-learning-book-pdf

started time in 2 hours

starteddkubb/axiom-rs

started time in 2 hours

startedsorbet/sorbet-typed

started time in 3 hours

startedscionproto/scion

started time in 15 hours

created repositorydkubb/axiom-rs

created time in 15 hours

issue closedsameersbn/docker-gitlab

Help: Terraform integration not enabled

Hi there, first of all i want to thank you so much for maintaining and sharing this project. We are using the setup provided heres in our company for many years now - always reliable! Great Job!

We are currently planing to use gitlabs terraform integration.

https://docs.gitlab.com/ee/user/infrastructure/terraform_state.html

We are running on 13.5.3. But the feature doesn't seem to be enabled. The Operation menu doesn't show the expected terraform button:

Bildschirmfoto 2020-11-27 um 09 59 24

In my understanding the feature should be enabled by default using this installation:

https://github.com/sameersbn/docker-gitlab/blob/e2d7d726f5530d5d0343cd0ef985e762a47513f3/assets/runtime/config/gitlabhq/gitlab.yml#L365

Unfortunately I cannot find the origin of the missing feature. Did someone of you use the terraform integration with this installation? Is there a way beside looking into the gitlab.yml to check if the feature is enabled on the instance?

Thank you for your support.

closed time in 17 hours

martinspaeth

issue commentsameersbn/docker-gitlab

Help: Terraform integration not enabled

Seems like the changes and additions for terraform found there way into the foss repo just recently:

https://gitlab.com/gitlab-org/gitlab-foss/-/commit/4ff56b118438f4fa6191b691fd968c75d8e94d5a#6cfdbb6518cd737e4ed15ff7c2ed1430adc456e0

Looking forward to the next release

martinspaeth

comment created time in 17 hours

startedgithub/codeql

started time in a day

startedprotontypes/awesome-sustainable-technology

started time in a day

startedtlhunter/distributed-node

started time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

Yeah, it should help. Also, you can have simpler types in the entity compared to relations, attribute :name, Types::String will be enough.

hieuk09

comment created time in a day

issue closedrom-rb/rom

AutoStruct does not respect type definition when creating

Describe the bug

This problem may be similar to https://github.com/rom-rb/rom/issues/581. When using auto_struct, the object returned after creating a record doesn't use the configured type definition.

To Reproduce

Full script: https://gist.github.com/hieuk09/11feb1ef50061ef74ce5c5168e4fc0d9

Types::UpcaseString = Types::String.constructor { |input| input.upcase }

class Entities::User < ROM::Struct
  attribute :name, Types::UpcaseString
end

user = UserRepository.new.create(name: 'user1')
user.name
# => "user1"

user = UserRepository.new.users.map_to(Entities::User).first
user.name
# => "USER1"

Expected behavior

auto_struct should apply correctly upon creation.

Your environment

  • Affects my production application: YES. Currently I'm avoiding this by monkey-patching ROM::StructCompiler to not overwriting my configuration.
  • Ruby version: 2.7.2
  • OS: MacOS

closed time in a day

hieuk09

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

Hmm, currently we need to specify attribute in entity because we use fabrication gem, and it uses .new to initialize. We'll check out rom-factory to see if switching to it solves that problem.

Thank you very much @flash-gordon, I'll close this issue now.

hieuk09

comment created time in a day

startedHoTT-Intro/Agda

started time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

why though? The struct compiler uses schema attributes to build structs. You should be good with just

module Entities
  class User < ROM::Struct
  end
end
hieuk09

comment created time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

Thank you, this solution works for me. However, it seems weird for me that I need to define an attribute twice in different places for the same purpose. IMHO, this is error prone because if I forget to add the attribute configuration in either relation or entity, it'll cause error. Are there any ways to avoid the duplication?

hieuk09

comment created time in a day

startedswisscom-blockchain/polkadot-k8s-operator

started time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

@hieuk09 you need to put that code to the relation (users), not the struct. If you infer the schema, it'll be fine to combine inferred schemas with manually defined attributes

class Users < ROM::Relation[:sql]
  schema(infer: true) do
    attribute :name, ...
  end
end

See https://rom-rb.org/learn/core/5.2/schemas/#inferring-schemas

hieuk09

comment created time in a day

startedhkalexling/Mango

started time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

@flash-gordon: I tried your suggestion with the code above, and it doesn't seem to work:

module Entities
  class User < ROM::Struct
    attribute :name, Types::String.meta(read: Types::String.constructor(&:upcase))
  end
end

user_1 = repo.create(name: 'abc').name # => "abc"
user_2 = repo.users.map_to(Entities::User).first.name # => "abc"

I also tried the second suggestion (Types::String.constructor { |v| v.upcase }.meta(read: Types::String.constructor { |v| v.upcase })) but it doesn't work either. Did I miss anything here?

hieuk09

comment created time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

@hieuk09 I get that, why wouldn't you use read types on relation attributes instead?

schema do
  attribute :name, Types::String.constructor { |v| encrypt(v) }.meta(read: Types::String.constructor { |v| decrypt(v) })
end
hieuk09

comment created time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

@flash-gordon: Actually, running constructor type when loading the entity is intentional here. In our code base, instead of the Type::UpcaseString, we use a Type::DecryptedString to decrypt PII in DB. Because ROM::Struct is immutable, it's not possible for us to lazily decrypt string and cache it; on the other hand, we don't want to decrypt the same string every time we read user.name either. Since we read PII almost every time we load user, decrypting string when constructing entity is a trade-off we made.

hieuk09

comment created time in a day

issue commentrom-rb/rom

AutoStruct does not respect type definition when creating

Hm. This is actually intentional. Performance-wise it's not efficient to run constructor types every time you load an entity from storage. I would suggest you moving attribute transformations to the relation attribute :name, Types::String.meta(read: Types::String.constructor(&:upcase)) <- it's the "official way" of doing this.

WRT entity structs here's the list of my thoughts, semi-ordered:

  1. Auto-generated structs must be instantiated via .allocate (.load in terms of dry-struct), it's a private API. For performance reasons. 99 of 100 times you don't need to run type checks and constructors. Obviously, it must be fully documented 😅
  2. User-provided structs should rely on the same API, otherwise, it'd be weird: you have a performance penalty just for using custom structs.
  3. Fall back to using .new when a struct with constructor types provided? I don't think it's a good idea, too magical.
  4. Issue a warning when we detect there's a constructor type in the struct? It may make sense.

/cc @solnic

hieuk09

comment created time in a day

startednfrumkin/forecast-prometheus

started time in a day

issue openedrom-rb/rom

AutoStruct does not respect type definition when creating

Describe the bug

This problem may be similar to https://github.com/rom-rb/rom/issues/581. When using auto_struct, the object returned after creating a record doesn't use the configured type definition.

To Reproduce

Types::UpcaseString = Types::String.constructor { |input| input.upcase }

class Entities::User < ROM::Struct
  attribute :name, Types::UpcaseString
end

user = UserRepository.new.create(name: 'user1')
user.name
# => "user1"

user = UserRepository.new.users.map_to(Entities::User).first
user.name
# => "USER1"

Expected behavior

auto_struct should apply correctly upon creation.

Your environment

  • Affects my production application: YES. Currently I'm avoiding this by monkey-patching ROM::StructCompiler to not overwriting my configuration.
  • Ruby version: 2.7.2
  • OS: MacOS

created time in a day

startedrubjo/victor-mono

started time in a day

more