<postmodern>
wasn't someone saying we could use morpher for migrations?
<postmodern>
could really use something for extracting a column into a unique model
solnic has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
solnic has quit [Ping timeout: 250 seconds]
solnic has joined #rom-rb
solnic has quit [Ping timeout: 255 seconds]
jordanyee has joined #rom-rb
rolfb has joined #rom-rb
snusnu has joined #rom-rb
snusnu has quit [Client Quit]
snusnu has joined #rom-rb
robmiller has joined #rom-rb
snusnu has quit [Quit: Leaving.]
solnic has joined #rom-rb
snusnu has joined #rom-rb
<solnic>
snusnu: hey
<snusnu>
solnic: yo
<solnic>
snusnu: just wanted to say one last task is left to fully decouple mappers from relational concerns ;)
<solnic>
and it's just moving methods that fetch identity values from mapper to...something else ;)
<solnic>
I'm thinking about something reusable like Identity object that exposes two methods: #from_tuple and #from_object
<solnic>
and it's done :)
<snusnu>
solnic: nice, sounds like a plan!
<solnic>
yeah it was always a temporary thing
<solnic>
I'm happy I finally got to refactoring it
<solnic>
after that's done I'll add Entity generator
<solnic>
snusnu: are you building anonymous entity classes?
<solnic>
I was thinking about setting up actual constants so that you could re-open them and add stuff
<solnic>
I'm also planning to experiment with a proper DI solution for rom
<solnic>
so that you won't have to refer to constants within the env
<solnic>
should help in isolated testing
<snusnu>
solnic: i'm generating anonymous classes, yes, and due to my app architecture, i've so far never had the need to reopen them (i basically only use them as data capsules, adding anything that computes/aggregates data slots in either presenters or views)
<snusnu>
i also had this concern about reopening, but then i thought, hey, only support it when you need it
<snusnu>
what i do tho, is five those classes reasonable names, so that #inspect gives me clues
<snusnu>
the rest is done by anima (re nice #inspect output)
<solnic>
snusnu: yes I am moving towards architecture where data coming from the db are encapsulated in value objects (immutable ones) so any logic lives in domain-specific objects that just use those values
<solnic>
I do see the need of re-opening though
<snusnu>
solnic: also what i do in my stuff, is that i allow to either reuse existing entity classes when i wrap/group, or generate new ones … sometimes it's cool to reuse an otherwise independent model, sometimes not (like, a few fields are missing, or additionally present)
<snusnu>
solnic: think hard about that need …
<solnic>
snusnu: well, my scope is broader than yours :)
<snusnu>
i was *very* tempted to support it, and forced myself not to (leaving the opportunity of course, to add them later=
<solnic>
well, we'll see
<snusnu>
still, i'd say, add it when someone needs it
<solnic>
I'll start with anononymous
<solnic>
yes that's the plan
<solnic>
I was just thinking out loud
<snusnu>
the way i see it now, i'd probably be happy enough if i could just grab the classes from the entity registry, and class_eval something on them
<snusnu>
and i can already do that, but don't need to
<snusnu>
it's really a matter of the app architecture tho, i guess
<snusnu>
solnic: also, re the architecture you're moving towards, i do that already, and i'm very happy with that
<solnic>
yeah I know, I did this in a smaller scale here and there and it feels SO GOOD
<solnic>
snusnu
<solnic>
snusnu: one more thing - what about loading aggregates? how do you do that?
<solnic>
separate entities?
<snusnu>
my domain model is a set of aggregate roots that get the app env injected (provides access to storage among other things), which only exposes business logic methods that use those immutable data capsules as data
<snusnu>
solnic: wdym by aggregates?
<solnic>
snusnu: user with address? :)
<snusnu>
heh ok
<snusnu>
ok, so what i do currently, is generate "base" model entities from the DM1 schema automatically, and yes, i define such aggregates with separate entities
<snusnu>
as i said tho, i support reusing wrapped/grouped objects, or generating them "inline"
<snusnu>
solnic: currently, i basically have 3 types of mapping scenarios, i have 1) a registry of params, those are hash transformers that potentially do coercion 2) a registry of models, those are object mappers generated from DM1 models, and 3) a registry of views (poor name), those are those are what you called aggregates, used in read views
<snusnu>
the last one, views, obviously are object mappers too