Open whysthatso opened 5 years ago
class Client < Hanami::Entity
end
class ClientRepository < Hanami::Repository
associations do
has_one :contact_point
has_many :invoices
end
def create_with_contact_point(data)
assoc(:contact_point).create(data)
end
def find_with_contact_point(id)
aggregate(:contact_point).where(id: id).map_to(Client).one
end
def find_all_with_contact_point
aggregate(:contact_points)
end
end
Hanami::Model.migration do
change do
create_table :clients do
primary_key :id
foreign_key :tax_id, :taxes
column :city, String, default: 'n/a'
column :name, String, default: 'n/a'
column :country, String, default: 'n/a'
column :email, String, default: 'n/a'
column :form_of_adressing, String, default: 'n/a'
column :street, String, default: 'n/a'
column :street_nr, String, default: 'n/a'
column :vat_id, String, default: 'n/a'
column :vat_id_country, String, default: 'n/a'
column :zip_code, String, default: 'n/a'
column :created_at, DateTime, null: false
column :updated_at, DateTime, null: false
end
end
end
Can you handle the default values at the model layer instead? A "Custom schema" might get you what you want.
Semantically, the city is nil
(or null
in SQL lingo): it wasn't provided. That you want to present it as "n/a" shouldn't affect how you store it.
Honestly, I'd probably go higher than the model and handle this in a Presenter
.
I know this might not be the answer you want, and there might be some underlying issue here that we need to fix, it just seems like there's a better way to accomplish what you're trying to do. (Maybe this DB interacts with another app and that's why you have to do it this way, I don't know.)
I guess a work-around would be to convert the entity into a hash and compact it. Then all keys where the value is nil would be removed (empty strings would still be around though!) and defaults of the database should be filled in.
A better approach would be to have defaults specified in the entity. In that case one needs to create a custom schema... @cllns Couldn't the auto-discovery of the schema also consider defaults?
If the column allows NULL
s and you send a nil, this one will get persisted as this was what you asked for (or so the underlying layers think).
Same goes with the empty string. @whysthatso You can probably properly handle these with a validator either on the Action or Interactor level.
When invoking
ObjectRepository.new.create
, a new Object is indeed persisted with the default values as defined in the migration.When invoking `ObjectRepository.new.create( Object.new( attribute1: '', attribute2:'foobar', attribute3:nil ) an Object with all these attributes set is persisted, but neither empty string nor nil is set to the default value.
Possibly unimportant context: The attribute values are received from a form object that is handled inside an interactor. The model is part of an
has_one
association: ThisObject.has_one OtherObject.Any more info needed?