<solnic>
I will timebox it. I will either do it or fail miserably
<snusnu>
hah
<solnic>
snusnu: re morpher, I would expect every project that uses it to expose its own DSL that fits within a given domain
<solnic>
for instance: virtus could be one
<solnic>
rom could have its own
jgaskins has joined #rom-rb
<solnic>
notice that both projects have completely different DSLs
<solnic>
I'm not sure if we could have one convenient DSL for such a powerful beast as morpher
<solnic>
since you can do crazy shit with it I'd expect many many DSLs on top of it
<solnic>
along with various extensions to morpher itself
<snusnu>
having only one would make no sense, morpher itself should never provide more than the sexps imo
<solnic>
yeah I agree
<snusnu>
but there could and imo should be one dedicated gem, that makes mapping from nested hashes to objects easy
<snusnu>
and that by itself has nothing to do with rom
<snusnu>
like i pointed out in the parameter sanitization usecase
<solnic>
snusnu: see, that's why I want to collapse those repos
<solnic>
we can't even know what will come out of that
<snusnu>
yeah
<solnic>
how could we possibly split those repos so early
<solnic>
well, we couldn't, I'm collapsing with crazy git magic tricks RIGHT NOW
<snusnu>
awesome!
dkubb has joined #rom-rb
<dkubb>
good morning
<snusnu>
hey dkubb
<dkubb>
git subtree ftw
<solnic>
morning dkubb
<solnic>
thanks for the axiom release
<dkubb>
yeah I was working up to it
<solnic>
everything's working fine
<dkubb>
had to make sure I could eliminate all the git references in the Gemfiles and make sure they all still passed ci
<solnic>
yeah I need to somehow build an env switch where I could say "ok buddy, today we're working against master for this and that repos" :D
<solnic>
+ it's not that simple, sometimes you want to use master for X repo and something-else for Y repo etc
<solnic>
messing around with Gemfiles is terrible
<solnic>
anyhow, git subtree, bbiab ;P
<dkubb>
yeah, that's some git vodoo right there
<solnic>
I did that in the past in DM1
<solnic>
felt like voodoo for sure
<dkubb>
I don't know if it's part of git itself yet, or still a plugins
<dkubb>
*plugin
<snusnu>
solnic: re the extraction of a mapping dsl for morpher, i'm gonna wait with that until i'm happy with how i construct my param object mappers with morpher sexps, and only *then* distill that knowledge into a DSL gem
<solnic>
snusnu: sure that's a reasonable thing to do
<snusnu>
solnic: lots of stuff in my app can still be dried up, and i assume that after a few cycles of doing so, i'm in a better position to come up with something .. because i've *used* it already then
kleech has quit [Remote host closed the connection]
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
<snusnu>
mbj: around?
skade has quit [Quit: Computer has gone to sleep.]
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
jgaskins has quit [Quit: This computer has gone to sleep]
kleech has joined #rom-rb
jgaskins has joined #rom-rb
kleech has quit [Remote host closed the connection]
<solnic>
great now I'm messing around with git filter-tree :D
<snusnu>
lol
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
lfox has joined #rom-rb
jgaskins has joined #rom-rb
<solnic>
this gonna take a while O_o
<solnic>
as in, the rewriting takes a while
skade has joined #rom-rb
<snusnu>
solnic: just cause i'm curious, what "problems" are you experiencing?
<solnic>
snusnu: with what?
<snusnu>
well with the rewriting :)
<solnic>
git rewriting
<solnic>
history
<solnic>
slow
<solnic>
:)
<snusnu>
ahh ok heh
<solnic>
I was just whining on irc, move on ;)
<snusnu>
lol
<solnic>
ok almost there
mbj has quit [Quit: leaving]
jgaskins has quit [Quit: This computer has gone to sleep]
skade has quit [Quit: Computer has gone to sleep.]
<xybre>
I haven't taken the plunge into git subtree yet. I've been using submodules pretty extensively though. Once you get the incantation right its not so bad.
<xybre>
Hahaha, jsut kidding, its horrible.
<dkubb>
lol
<dkubb>
I use submodules for some things just fine
<xybre>
dkubb: When I really dislike someone in an interview I'll ask them "What command removes a submodule from a git repo"
<snusnu>
that's how damn easy it is to do input sanitization/mapping with morpher
<snusnu>
it's too cool
<snusnu>
this is also the non-rom usecase i mentioned in the issue recently
<dkubb>
xybre: that's evil. I had to google it and I didn't realize there was: git submodule deninit <module>
<dkubb>
we deinit
<dkubb>
*er
<xybre>
dkubb: It was only added this past year iirc
<solnic>
today I am a git plumber
<solnic>
xybre: years have past, I still wouldn't answer that question
<xybre>
dkubb: Its kinda trick question anyway, because that still doesn't remove the submodule, you then have to remove it from the .gitmodules, and git rm -rf the directory. Then you can commit the removal.
<solnic>
yeah submodules is the most unfriendly feature ever made
skade has quit [Quit: Computer has gone to sleep.]
<xybre>
I mean, its pretty easy to automate. A git-submodule-rm wouldn't be hard to make. Do I need to do it myself?
<xybre>
I wonder if its one of those weird Linux quirks, where he thinks thats okay and will refuse to change it.
<snusnu>
and that one still needs to be sharpened (by creating a dynamic regex to scan the string in different radix/bases before turning it into an int)
<snusnu>
eventually, coercions will probably be a morpher plugin (coercible)
<cored>
hello all
<cored>
solnic: I was thinking about an article from you today, testing controllers
kleech has quit [Ping timeout: 248 seconds]
<cored>
solnic: I have mixed feelings about testing those still, even when I tested for things like redirect and render new
<solnic>
cored: why? testing redirects for various cases is really easy
<solnic>
it's great to write those tests because you are begin reminded how terrible controller layer in rails is
<solnic>
:D
<solnic>
begin/being
<cored>
yes
<cored>
that's the thing
<cored>
I'm working on an app at the moment
<cored>
driving myself from a feature file in cucumber, now I went to the part of dynamic behavior for the controller, but I just decide to go ahead and build a new service and test that out
<cored>
without adding any logic to the controller at all, which means I won't have to unit test it also. But then again as I said I have mixed feelings about this
<solnic>
it's nice to rely on service objects in controller and just use mocks in controller tests
jgaskins has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
develop7 has quit [Ping timeout: 272 seconds]
snusnu has quit [Quit: Leaving.]
<dkubb>
usually what I do is make it so the controller is only responsible for taking the parameters and passing them into my service, as well as rendering success or errors
<solnic>
yeah that the approach I've taken as well
<travis-ci>
[travis-ci] rom-rb/rom#10 (master - e244ddf : Martin Gamsjaeger): The build has errored.
travis-ci has left #rom-rb [#rom-rb]
<xybre>
I'm about to write yet another mapper object to convert from this messy data schema (currently dumped into a yaml file) into a sane data model that can be presisted in a database. Likely, we'll need to run this task a few times, during development, testing, and finally in production (once for the bulk import, then again to keep in sync until it goes live).
<xybre>
I don't suppose there's any obvious tools to do that that ye might know of.
<snusnu>
xybre: i'm about to leave, but for mapping nested hashes into objects, use morpher
<solnic>
we briefly talked about coercions with Markus today
<solnic>
right, we talked about coercible
<solnic>
so, mbj thinks coercible's interface is too wide
<solnic>
as in it does too many coercions :D
<solnic>
he gave '10e10' as an example
<xybre>
Oh, I discovered that we're using Virtus here, and have been since before I was hired (just started here a week ago).
<dkubb>
that is a good example. I'd be happy with just integer and float coercion, without scientific notation
<dkubb>
maybe we/I got a bit carried away with what we could coerce ;)
<solnic>
we talked about refactoring coercible so that morpher can use it
<solnic>
but mbj thinks it will be simpler to add coercions directly to morpher
<solnic>
mostly because morpher needs inversible coercions
<solnic>
maybe coercible will be retired ;)
<dkubb>
yeah
<dkubb>
we could always extract coercible v2 from it too
<namelessjon>
So, speaking as someone who occasionally uses scientific notation on occassion, removing support for it seems bad.
<solnic>
yeah exactly
<dkubb>
assuming there's a need to use it stand-alone
<solnic>
namelessjon: yeah I agree SOMETHING must support this SOMEWHERE
<solnic>
we just need to figure good place for that
<dkubb>
namelessjon: do you often receive strings from users containing scientific notation and want it to be coerced into a float?
<solnic>
we are dealing with various contexts where coercions happen
<solnic>
so it's important to use correct coercions in right places
<dkubb>
yeah, that's probably the main issue. coercions from a web app are different from coercions from the db, etc
<namelessjon>
dkubb: No so much from users, but I have used it as part of some data-munging from csv files.
<dkubb>
I would generally want something a bit more restrictive for user input
<dkubb>
and a bit wider for trusted data sources
<dkubb>
namelessjon: yeah exactly
skade has joined #rom-rb
<solnic>
yeah I agree that what coercible can do is handy
<dkubb>
solnic: in axiom I need coercions too
<solnic>
dkubb: huh I completely forgot!
<solnic>
dkubb: where exactly?
<solnic>
shit travis is not picking up rom repo :(
<dkubb>
being able to invert a coercion is really handy too, since I can propagate writes across those operations (I don't want to get into specifics just yet though until I have a concrete example to show, since it's hard to explain)
<dkubb>
solnic: like if you want to coerce a string "y" or "n" into a boolean
<dkubb>
solnic: obviously if I can, I want to push that down into the database if it supports it, but for in-memory relations or limited databases I need it
<namelessjon>
dkubb: I'm not sure how best to restrict it down, but just dropping it because you wouldn't want it in a webapp is less than ideal
<dkubb>
the tuple that comes back would have a boolean value, whereas in the database it would be y/n or 1/0, etc
<dkubb>
namelessjon: yeah you're probably right
develop7 has joined #rom-rb
<solnic>
dkubb: wait, that's interesting - so you're planning to add that to axiom directly?
<solnic>
because I could swear mbj thinks it should be on a higher level, maybe I didn't understand it correctly
<solnic>
snusnu: ^^ ?
<solnic>
level/layer
<snusnu>
solnic, dkubb: yeah, both mbj and i think that this is stuff that should be handled in (axiom) adapters
<snusnu>
an axiom schema (with gateway backed relations) should only ever contain "user land" tuples .. that are "readymade" for rom-mapper … then you can reuse queries for reporting where tuples are enough, for ones that map into domain objects
<snusnu>
since those db type coercions are db specific, an axiom adapter seems to be the right place to do this mapping
<snusnu>
morpher is able to easily do that
<snusnu>
when i said "that are readymade for rom-mapper" above, i meant "readymade for the domain"
<solnic>
snusnu: wellllll you forgot to mention morpher is missing coercions
<solnic>
snusnu: I can work on it, from time to time
<solnic>
I'd prefer to focus on session after finishing mapper/morpher fun
<solnic>
and I gotta say I'd love to prototype that lazy-loading interface I mentioned to you last week
<snusnu>
solnic: i can finish the port to morpher within a few hours, i'll leave for a party in a few minutes, but i will *definitely* do it before tuesday
<solnic>
snusnu: OK then I'm gonna wait :)
<snusnu>
solnic: also, awesome work on the repo merge!
<solnic>
snusnu: yeah I'm sure github's background jobs are consipiring to kill me now
<solnic>
"bloody hell who pushed 1700 commits at once dammit"
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
solnic has joined #rom-rb
postmodern has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
cored has quit [Ping timeout: 240 seconds]
skade has quit [Quit: Computer has gone to sleep.]
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
<dkubb>
wtf is going on with ruby-head. is it' blowing up on adamantium? maybe I need to look at the code and rework it, as well as reporting something upstream
<dkubb>
solnic: re: coercions. yeah, sometimes you need to do it in axiom too. consider when you're joining two relations, but the types aren't exact, you need to cast it from one type to another in order for them to join properly. this is the kind of thing that can be pushed down to an SQL based database in many cases.
<dkubb>
solnic: at the same time, anything we add needs to be available to the in-memory ops, since we need it for fallback for less capable databases
<solnic>
dkubb: so, adapters can't handle that? that's too early?
lfox has joined #rom-rb
<dkubb>
solnic: I think we can have it so adapters can rewrite the query to handle what they support, but I think I would want to define an object that can do it on behalf of the adapter
<solnic>
ah gotcha
<dkubb>
solnic: like maybe something where the adapter specifies "I can handle restrict, project, but not union" .. and so on through all the ops
<dkubb>
and then the object would know how to rewrite the query so everything the database can handle is pushed down, and the in-memory processing is minimized
<dkubb>
ideally we would want to eliminate in-memory processing, but we know some datastores are limited
<dkubb>
if the query doesn't use some unsupported operation, then ideally we'd run it all in the database
<dkubb>
I don't yet know what the interface will look like, but I know roughly how it'll work to rewrite the query
<dkubb>
it's essentially the same process as what axiom-optimizer does now, only it'll have to be configurable
<dkubb>
I will probably be able to have it use parts of axiom-optimizer
<dkubb>
axiom-optimizer is also streamlined to only support "obvious" optimizations, like collapsing restrict(restrict(relation, predicate1), predicate2) into restrict(relation, predicate1 & predicate2) for example
<dkubb>
what I could see is axiom-optimizer taking into account the adapter for each base relation, and applying different "chains" of optimizations depending on what the adapter can support
<dkubb>
that was kind of the original plan when I set out to write it