<dkubb>
solnic: lol, I know you can see the logs :P .. yeah I know what it does, I was just curious if at some point people will be able to mix in specific modules or if they will want to use the .model, .module and .value_object methods as the interface
warmwaffles has joined #rom-rb
<dkubb>
solnic: unless they are all configured exactly the same, I might be inclined to suggest having include Virtus::Model (for default behaviour) and Virtus::Model.new(...) for configuration, and same with Virtus::Module, Virtus::ValueObject
<elskwid>
dkubb: It's like talking to a ghost.
<warmwaffles>
solnic pops in and out
<elskwid>
What's great is the log amounts to eavesdropping. :-)
<warmwaffles>
it's a nice to have
kalleth_ has joined #rom-rb
joakimk_ has joined #rom-rb
<warmwaffles>
dkubb: I have a relation and I want to sum the columns
kenphused has quit [Remote host closed the connection]
snusnu1 has quit [Quit: Leaving.]
snusnu1 has joined #rom-rb
mbj has joined #rom-rb
warmwaffles has joined #rom-rb
dkubb has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu has quit [Ping timeout: 245 seconds]
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
kenphused has joined #rom-rb
<snusnu1>
warmwaffles: hey, i read the logs and saw you were complaining about weakly typed json data, and coercion of that … you might want to have a look at http://github.com/mbj/ducktrap.git .. it's far better suited for turning nested json objects into "rich" domain object graphs
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
warmwaffles: it was built mostly for that exact usecase, it allows you to do arbitrary coercions (and has a predefined set of those to reuse)
<snusnu>
warmwaffles: also, it provides you with detailed error tracking, and it fails the coercion if your coercion rules couldn't be applied to the data it received
<snusnu>
warmwaffles: so it can (and does) also act as a data sanitizer
<snusnu>
warmwaffles: like, nail the params an action accepts down with ducktrap, and then be certain that nobody can do foolish/dangerous things with crafted parameters
zekefast has quit [Read error: Connection timed out]
kenphused has quit [Remote host closed the connection]
<dkubb>
snusnu: so you can define a ductrack and then use it to transform a list of data into some other form that axiom can consume?
<snusnu>
dkubb: yes
<snusnu>
dkubb: ducktrap was initially built to transform "serialized objects (like, json)" into a ruby object (graph) … it really is a data transformation language .. whenever you have some structure in some format, you can write a transformation that will turn it into "another format" (and back)
<snusnu>
dkubb: it is *very* powerful and useful in a lot of different contexts
mbj has quit [Ping timeout: 245 seconds]
<dkubb>
snusnu: so is there anything on the ROM side you're being blocked by?
<dkubb>
I know I ask this every week :P
<snusnu>
dkubb: heh, lemme think (again ;)
<snusnu>
dkubb: i'm pretty sure tho that nothing's *blocking* anything right now
<dkubb>
that's good to know
<snusnu>
there are a few things that'd be nice to have in the future, but i wouldn't say that there are any blockers atm
<snusnu>
i'm still optimizing my dev env today, so that i can get back to work tomorrow .. and then i will continue with the rom compatible mapper spike that uses ducktrap under the hood
<snusnu>
that will lead me to a DSL for mapping EV/EC too, expect to see ideas/spikes the next week
<dkubb>
cool. I have a bit more refactoring to do in wrap and group
<snusnu>
one thing i'd like/need to experiment with soonish, is support for server generated values (keys)
<dkubb>
ahh yes
<dkubb>
I would probably expand that to think about things as server generated default values
<snusnu>
yeah, that sounds feasible
<dkubb>
where a key just happens to be a default for an attribute that is part of a key
<snusnu>
exactly
<dkubb>
I don't see them being much different. from the pov of axiom and rom, the mechanism to set default values should be a black box
<dkubb>
and it's not even so much server generated, but rather adapter generated
<snusnu>
right
<dkubb>
the adapter is concerned about where it gets the value from
<snusnu>
the api would probably be something like ValueProvider#call(tuple) => tuple
<snusnu>
?
<dkubb>
I'm not sure yet
<snusnu>
i.e., it'd return a tuple with default values included
<snusnu>
yeah, just a rough idea, but i expect it to be something that receives an incomplete tuple, and returns a complete one .. probably based on some additional info
<dkubb>
from the pov of the #insert command, it'll return a new relation with the values filled in
<dkubb>
at the tuple level, I'm not sure what the api will look like
<snusnu>
yeah, me neither, my thoughts are simply based on the premise that at some point there's an incomplete tuple, which has to be turned into a complete one at some other point
<dkubb>
there could even be something like: Adapter#set_defaults(tuple) => new_tuple
<dkubb>
the tuple doesn't really have adapter information, so it's probably not going to be a tuple method
<dkubb>
unless we make it so you have to pass in the adapter
<snusnu>
yeah
<dkubb>
like Tuple#set_defaults(adapter)
<dkubb>
but I don't like using 'set' in the method name because it implies mutation
<snusnu>
hm, feels weirdish .. tuples are in a "different domain" .. adapter is a concept on top of RA
<dkubb>
Tuple#merge_defaults(adapter)
<dkubb>
hmm.. still not sure yet
<dkubb>
do you even need a tuple level method to do it?
<snusnu>
no idea tbh ;)
<dkubb>
I would probably suggest telling axiom to take care of it
<snusnu>
i just happened to start thinking about it in tuple terms as those are the ones having to "change"
<dkubb>
it'll be way easier than manipulating the tuples on your own.. it's probably better than ROM not really try to do too much at the tuple level
<snusnu>
full ack
<dkubb>
from ROM's pov it should get an enumerable with hash-like objects
<snusnu>
yes
<dkubb>
and have it be a dumb delegator as much as possible, especially for finders
<snusnu>
yes
<dkubb>
if you could wrap [ { id: 1, name: 'Test' } ] in a ROM::Relation and feed it into the system that would be awesome
<dkubb>
then it would make it super easy for people to unit test ROM stuff
<dkubb>
(or something, I realize I'm glossing over lots of details)
<snusnu>
not sure if i follow, i'd expect that to work "anyway" …at least in the sense that ROM will happily create ROM::Relation instances as long as the data used to construct the relation can be coerced into a relation … then it's a matter of where to set up that data
<snusnu>
unless i'm missing something
<dkubb>
I just wondered if it depends on axiom relations, or if all it cares about is that it be enumerable and yield hash-like objects
<dkubb>
I guess right now it has hard coded methods for #project and other methods
<snusnu>
it currently delegates all those RA ops directly to the underlying relation
<snusnu>
how i envision unit testing ROM interfacing code (i.e. if you can call that unit testing, you might call it integration testing already?) .. is that there's a sample test data set, that's used to populate the memory adapter, running the app backed by that
<snusnu>
that way it'd be blazingly fast
<snusnu>
it's also fine for development, you don't need real persistence
<dkubb>
yeah that should be really fast
<dkubb>
I'm going through axiom and cleaning up some mutations
<dkubb>
it's been uncovered for too long
<dkubb>
I plan to chip away at it. it shouldn't be hard, it was 100% heckle covered all the time
<dkubb>
of course mutant is way tougher on the code
<snusnu>
heh, yeah
<dkubb>
I'm also going to move a few things around inside axiom in preparation for separating it into axiom-logic and axiom-relation
<dkubb>
axiom will still bind everything together
<dkubb>
I also need to start making a list of things for people to help with. like extracting the support libs into other repos
<dkubb>
I need to make some stub gems/repos for those
<snusnu>
yeah that'd be nice, it's easier to start with stuff, if some basics are already there (that goes for ourselves as well as potential new contributors)
<dkubb>
I should also make a rom-skeleton repo maybe
<dkubb>
something you can pull down and then do a find/replace to make the gem you want
<dkubb>
or maybe just have devtools have a skeleton command
<snusnu>
eventually it'd be nice to have something like that in devtools, yes
<snusnu>
even tho i don't find myself writing new gems *particularly* often, it'd still save time in those rare occasions
mbj has joined #rom-rb
<mbj>
hi
benjamins_log_bo has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
knowtheory has joined #rom-rb
mbj has quit [Ping timeout: 268 seconds]
irclogger____ has joined #rom-rb
bf4 has joined #rom-rb
irclogger____ has quit [Ping timeout: 248 seconds]
irclogger____ has joined #rom-rb
bf4 has quit [Ping timeout: 272 seconds]
bf4 has joined #rom-rb
irclogger____ has quit [Ping timeout: 246 seconds]
bf4 has quit [Ping timeout: 268 seconds]
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
<warmwaffles>
snusnu: Just saw that duck type repo, I'll take a look around