skade has quit [Quit: Computer has gone to sleep.]
rolfb has quit [Quit: Leaving...]
skade has joined #rom-rb
breakingthings has joined #rom-rb
snusnu has joined #rom-rb
zekefast has quit [Quit: Leaving.]
rolfb has joined #rom-rb
CraigBuchek has joined #rom-rb
zekefast has joined #rom-rb
<mbj>
snusnu: morning
<CraigBuchek>
snusnu: Thanks for the feedback. I see what you're saying now. That's why I wanted feedback on the README and direction I was going.
<CraigBuchek>
snusnu: You're right - it does make more sense to keep the mapping outside of the model class.
snusnu has quit [Quit: Leaving.]
cored has quit [Ping timeout: 272 seconds]
<zekefast>
Hi, guys! I'd like to ask why you plan save object to session if it was instantiated from session? https://github.com/rom-rb/rom#3-work-with-plain-old-ruby-objects . It seems like unnecessary work in ActiveRecord style. It seems to me that if model instance was attached to session there should be enough to save it on flush (in case of new) or update.
<zekefast>
Could somebody shed some light on that? Thanks in advance!
<dkubb>
I merged in nest/unnest into axiom master last night
<mbj>
dkubb: Nice!
<mbj>
dkubb: I'll ping the arangodb guys, their AQL cann do nest unnest natively.
<dkubb>
I noticed that axiom-optimizer has some spec failures after the axiom-types integration. I really wish travis had dependency testing
<dkubb>
as much of a pain it was to manage, our old jenkins setup was probably superior
<mbj>
I think in sum travis is superior.
<mbj>
But lets try circle CI ;)
<mbj>
I have a commercial account on circleci and can easily use it for my OSS stuff.
<mbj>
Once they have badges I can try to setup all rom* axom* there.
<dkubb>
circleci can't do a testing matrix
<dkubb>
we'd have to lock it down to just one ruby version, which is a regression even further imho
<mbj>
Yeah, forgot about this restriction.
<solnic>
zekefast: it's because actions are explicit, by building a new object through session you start tracking its state, it doesn't mean it must be saved automatically, we could provide such behavior based on configuration though. I expect session will have various strategies (that's how it's done in other DMs)
snusnu has joined #rom-rb
<zekefast>
solnic, Thanks! So it means, I could configure the strategy which track everything related to session and save/update it on flush. Did I understood you right?
<solnic>
zekefast: that's something we could do at some point. session is in a very early stage right now so a lot can change
<zekefast>
solnic, Got it! Thanks!
zekefast has quit [Quit: Leaving.]
<solnic>
dkubb: hey, I'm super happy to see nest/unnest in master! congratz
<dkubb>
thanks
<dkubb>
it wasn't too hard once I sat down to do it
<dkubb>
I got a few nice refactorings out of it too
<dkubb>
I'm curious to see how it'll work with ROM::Relation
<snusnu>
dkubb: yeah, congratz from here too! i'm going to start experimenting with it during the weekend
<snusnu>
dkubb, solnic, mbj: i'm going to try injecting ducktraps into rom-relation, and see what needs to be done for either (rom-mapper or ducktrap) api for it to "just work"
<solnic>
snusnu: I'd suggest using ducktrap as an external dependency
<solnic>
snusnu: as I mentioned session relies on a broader interface, not just load/dump
<snusnu>
solnic: i know, but i want to to look at it without session glasses on for now. i need something that can properly map ECs resulting from nest operations, and ducktrap can do that (i'm actually experimenting with this to use it in my app)
<solnic>
snusnu: well, that's trivial
<snusnu>
solnic: it's more experimentation than actually "changing" anything in rom-relation
<solnic>
snusnu: I can already say it's just gonna work
<solnic>
just just need to inject an object which responds to load/dump
<snusnu>
i know
<solnic>
I suspect building a ducktrap mapper using relation header should be easy
<snusnu>
it sure is
* dkubb
still has no idea what ducktrap does
<mbj>
dkubb: I can offer a 10min hangout describing it in my limited english.
<mbj>
dkubb: I successfully described it for my team members and they are VERY happy to have it.
<dkubb>
mbj: sure
<mbj>
dkubb: So just call me on hangout if you wanna have it NOW (or later)
<dkubb>
sure, if you're available now that'd be awesome. I haven't really started work on my end
<mbj>
dkubb: no problem, I finished my commercial day.
<mbj>
I'm on stable 8h / day with commercial work now.
<solnic>
snusnu: I find those NEW_PERSON constants to look very ugly ;)
<snusnu>
(that last call needs a .output too)
<snusnu>
solnic: get over it
<snusnu>
:p
<solnic>
snusnu: no :)
<snusnu>
hehe
<mbj>
snusnu: dont ruin my "mbj finally has to explain sth to dkubb" chance ;)
<snusnu>
mbj: hehe, please do!
<mbj>
:D
<solnic>
I wonder if I could just plug ducktrap into virtus for 2.0 and call it a day
<snusnu>
solnic: srsly tho, how and where you store your ducktraps, really is up to you
<snusnu>
solnic: they're instances tho, and it makes no sense having a lot of them around, so a const is a good fit imo
<solnic>
snusnu: hey I know, I was just teasing :)
<snusnu>
solnic: heh, i guess, you could
<snusnu>
i really think that with a more tailored DSL, ducktrap can (and should) be our "real mapper" .. i'm not saying it should expose the mapper API we need in rom, but it can definitely do all the actual mapping work, from within an object that implements the API needed by rom
<snusnu>
the more tailored DSL btw needn't be implemented in ducktrap, that's fine to implement in rom
<snusnu>
mbj: btw, i renamed Cookie::Serializable to Cookie::Header last night, and i'm pretty happy with that new name now
<snusnu>
mbj: remember, no inheritance involved ;)
<mbj>
snusnu: I failed to explain it ;)
<mbj>
snusnu: I dont find good examples in my gist history and expected to find them while talking to dan ;)
<snusnu>
mbj: to dkubb?
<mbj>
snusnu: yeah
<snusnu>
hehe
<mbj>
snusnu: I wasnt prepared ;)
<mbj>
snusnu: I prepare the "golden example" now.
<mbj>
snusnu: help me once it is up
<snusnu>
dkubb: did you see my short explanation above? based on simple code examples?
<snusnu>
mbj: will do!
<solnic>
snusnu: I agree, we just need to figure out where to stick the "missing" interface for session
<solnic>
should it be part of mapper API or not
<solnic>
I always wanted a pure mapper lib anyway
<solnic>
ducktrap seems like a perfect fit
<dkubb>
would it be correct to describe ducktrap as a way to define a state machine that handles the transformation of data from one form into another?
<solnic>
not sure
<dkubb>
I find I need a mapper lib all the time
<dkubb>
I always think of it as a router, but same thing
<solnic>
it's about transforming input data into ruby objects and then back to raw data form
<solnic>
so you can't really talk about state I guess
<dkubb>
ahh ok
<solnic>
unless you consider raw data and ruby objects to be "states"
<solnic>
and obviously raw data is represented by ruby objects too :)
<dkubb>
it depends on the context. sometimes I do
<solnic>
and yes, I've always needed a solid mapping lib, since like..4 or 5 years now heh
<snusnu>
so yeah, you can think of ducktrap as a data transformation DSL, that defines both transformation directions .. you tell it how to go from input to output, and you always give it the inverse too … so from declaring the transformations *once* for both directions, you can "switch" between the 2 representations
<mbj>
snusnu: To see the advantage you have IMHO combine multiple ducktraps
<mbj>
snusnu: And you have to show an transformation error
<mbj>
snusnu: And the sharpness.
<dkubb>
Eiam: I'm not sure, dbussink probably knows more about how to solve it than I do. I was able to trace it back to the commit that caused the problem, but I'm not really a C programmer
<snusnu>
mbj: right, errors and nested ducktraps are a nice additional property, but the core concept is the same, the features you mentioned are nice side effects
<solnic>
I'm curious to see nested ducktraps
<solnic>
the DSL, it must be improved, it's extremely verbose
<Eiam>
dkubb: I see, he's in #datamapper so I'll ask there..
<mbj>
solnic: the DSL is VERY close to the internal AST nodes. I know it must be improved.
<mbj>
solnic: But it is currently saving you LOTS of typing already.
cored has joined #rom-rb
cored has joined #rom-rb
<mbj>
solnic: I showed my team the equivalent ruby for a simple 20LOC ducktrap and it was over 100loc, without history tracking
<solnic>
history tracking?
<dkubb>
it's funny that we don't have a dozen libraries like this already
<dkubb>
I guess everyone writes their data transformations as one-offs
<dkubb>
I know I generally do in many cases.. or I write my parser and generator separately
<dkubb>
to_json/as_json for generating, and a from_json for parsing, etc
<mbj>
solnic: You can see the transformation history in case of a failure.
<mbj>
solnic: Imagine you have a nested ducktrap, 5 levels.
<Eiam>
is rom-rb ready for production use?
<mbj>
solnic: For example a typical JSON post for a complex business transaction.
<Eiam>
I probably can't just swap out DM for ROMRB
<solnic>
Eiam: nope
<snusnu>
solnic: if a ducktrap transformation fails, #success? will be false, and #output will contain an error object .. that error object tells you the *exact* transformation that failed, and why it failed … so inside a deeply nested hash, you immediately see *which* nested key caused the transformation error, and why
<dkubb>
Eiam: it's not yet. it is probably ready for playing though
<mbj>
solnic: see snusnu ;)
<solnic>
snusnu: can you turn it OFF on demand?
<mbj>
solnic: Nope
<mbj>
solnic: But it would be easy.
<snusnu>
not yet i guess, but that's needed
<snusnu>
right
<solnic>
that's must have for ROM
<snusnu>
right
<mbj>
solnic: I did it in a branch and only got 5% performance improvement.
<mbj>
solnic: So AFAIK we should NOT proactively remove it. Its a very nice debugging feature. Do not optimize until benchmarking.
<dkubb>
mbj: how's the performance of ducktrap?
<snusnu>
it's not so much about performance, when used in rom, it shouldn't be used defensively .. once it hits rom, the app should've made sure that there can't be any errors anymore
<solnic>
rom should assume data coming back from the db is "loadable"
<solnic>
no need to perform fancy validation or error handling
<snusnu>
solnic: exactly
<mbj>
dkubb: Fast enough for my use cases. The biggest problem was deep freezing (see misfo patches)
<snusnu>
solnic: same goes for "on the way in"
<snusnu>
once data hits rom .. it MUST be clean
<solnic>
yup
<mbj>
I'd not worry about performance in this stage of the project. Keep it correct.
<snusnu>
otherwise, the app has architectural problems (well, imo at least)
<dkubb>
sometimes old data coming back isn't valid
<dkubb>
like in the case where your validations have become stronger
<dkubb>
but I have no idea how to properly handle that besides manually validating the existing records and fixing the ones that are now invalid.. I don't think you'd want stuff to blow up at runtime
<snusnu>
imo that's nothing the mapping layer should be concerned with
<dkubb>
yeah
<snusnu>
you'd have to write some scripts to clean the data i assume
<mbj>
solnic, dkubb, snusnu: If you guys *ever* worry about ducktraps performance: We have an AST, and you all know what unparser is capable off. We can always generate very efficient ruby from it.
<dkubb>
yeah
<snusnu>
mbj: i do not worry about performance at all
<mbj>
dkubb: I'm using my ducktraps to assert the structure of my data is correct before/after data migrations. (For NOSQL dbs).
<solnic>
mbj: oh I'm not worried about perf much, I'm just looking at things from a puristic pov
<mbj>
solnic: Sure.
<solnic>
as in, mapper on the rom level shouldn't do more than it's needed
<dkubb>
assuming the ducktraps are static, it could always be "finalized" and have ruby code generated from it
<snusnu>
mbj: but i don't wanna program defensively … it's no show stopper for me that ducktrap does error handling on that layer for the time being .. but conceptually, it shouldn't need to do it, so ideally, it wouldn't do it
<mbj>
solnic: A mapper should have error reporting. Just like a parser.
<mbj>
snusnu: You want your mapper to tell you why your data does not fit anymore.
<Eiam>
well this channel sure is more active than #datamapper =p
<mbj>
snusnu: It saves you LOTS of debugging time.
<snusnu>
mbj: good point actually, but still, it should at least be configurable
<mbj>
snusnu: Yeah, but NOT now.
<snusnu>
absolutely not now
<snusnu>
definitely no priority
<solnic>
Eiam: ROM is under heavy development so it's loud here :)
<solnic>
it's just that we should find a nice way of setting those up
<solnic>
otherwise ppl will be cargo culting whatever we show in the examples
<mbj>
solnic: +1
<solnic>
I'm trying to avoid global constants like hell
<solnic>
ESPECIALLY in rails
<mbj>
solnic: I'm a bottom up person. Get the objects/primitives right and than think about more.
<dkubb>
mbj: does ducktrap play nicely with coercible?
<mbj>
dkubb: coercible does not have inverse properties (now).
<mbj>
dkubb: I planned to add those to coercible, but did not have the time.
<solnic>
mbj: yeah I know man, same here, I'm just commenting on what I see
<snusnu>
solnic: fwiw, i went with storing the ducktraps in consts, because it was the easiest thing to do … there could just as well be some sort of registry that allows to access by some symbolic name
<solnic>
snusnu: I'd use a registry
<mbj>
solnic: Heh ;) We discussed that ducktrap so often, I'm a littlebit "thin minded" here ;)
<snusnu>
yeah, me too, eventually
<solnic>
one constant instead of many
<snusnu>
yeah
<mbj>
I expect ducktraps will be stored in vars.
<mbj>
*ivars
<mbj>
In the Rom::Mapper instance.
<solnic>
dkubb: we have a plan to change coercible interface so that ducktrap can consume it
<mbj>
solnic: Yeah
<solnic>
personally I want to do it as the next step before virtus 2.0
<snusnu>
depends, right, for rom, yes (re storing in ivars)
<solnic>
I would love to see if I can use ducktrap in virtus 2.0 too
<dkubb>
looking at the dsl, I see primitive(Hash); hash_transform { ... } .. and primitive(Array); map { ... }, I wonder if a better dsl would be: transform(Hash) { ... }
<mbj>
solnic: You *may* wanna consider ducktrap inside virtus. So you have a "transform success" or "error" stage.
<mbj>
dkubb: Yeah
<solnic>
yeah DSL is a very weak part of ducktrap, but with solid internals it's really a polishing fun to make it better :)
<dkubb>
then the connection between the primitive and what is being transformed is clear
<mbj>
dkubb: I focused on the internal objects, and mutation coverage.
<dkubb>
yeah
<mbj>
dkubb: Ducktrap is 100% mutcovered (at the time I released 0.0.1)
<dkubb>
I appreciate that too
<solnic>
mbj: I don't like those tests btw, as I commented already ;(
<mbj>
I'll happily incorporate all your DSL ideas.
<dkubb>
you just have to open up (most) ruby libs with pretty interfaces and see what the internals look like to know that top-down doesn't work too well
<mbj>
solnic: I said I like this tests, but only till I do my own test framework.
<solnic>
yeah exactly
<mbj>
solnic: I take the pain *for now*
<dkubb>
I kind of prefer bottom-up and top-down with a meeting in the middle :)
<solnic>
"yeah exactly" that was re dkubb comment on top-down approach
<solnic>
MOST of the libs are built like that
<solnic>
and it's hell and torture
<dkubb>
in ruby especially
<mbj>
:D
<mbj>
Yeah
<dkubb>
since it's so easy to make pretty dsls
<solnic>
yeah it's because it's so easy to buiold dls
<solnic>
lol
<solnic>
...
<mbj>
Most people start with DSLs and fuck it up.
<solnic>
ugh typo after typo
<solnic>
build* dsls*
<dkubb>
then you're like "oh, I'll just stuff all this compelxity here.. no one is ever going to need to see it and debug it because my dsl is so pretty "
<jfredett-w>
mbj: soon that will be easier... *points at katuv* -- I'm halfway there. :)
<mbj>
I started with a DSL, discovered object interface and focused there for iterations. Than come back and did some DSL work.
<mbj>
jfredett-w: :D
<dkubb>
and what do most rubyists do in the first 30 minutes? they run into some bug and have to dive into the guts
<jfredett-w>
100% mut covered too, though it took some learning about how it finds tests.
<mbj>
jfredett-w: Still did not had a chance to revisit your project :D
<solnic>
btw I'm thinking about using ducktrap in virtus because virtus has become a really complex beast with handling modules
<mbj>
solnic: Nice
<mbj>
I have some "private" additions to ducktrap
<mbj>
I have to rip them out of my clients code.
<mbj>
Most notably the XOR node.
<mbj>
It allow you some polymorphism.
<solnic>
so I kinda see version 2.0 as a major clean up that focuses on orchestrating all of the module-related crazyness and getting rid of all the mapping logic by leveraging ducktrap
<snusnu>
please do mbj ;)
<jfredett-w>
mbj: someday, I will make mutant use line-coverage to figure out what tests to run... but I think I'd need to make rspec katuv-able.
<mbj>
jfredett-w: I have a very strong opinion about line-coverage is NOT the best solution. But I'll definitively support this.
<mbj>
solnic: I'm planning to work on all my oss stuff.
<solnic>
mbj: does ducktrap use ast?
<solnic>
as in the gem?
<mbj>
solnic: I have mutant, ducktrap, unparser, sql, aql, axiom-arango-adapter, axiom-mongo-adpater, axiom-elasticsearch-adapter, esearch, on my list....
<mbj>
solnic: I could take 10 years off with OSS work ;)
<mbj>
solnic: But I have 3 weeks.
<mbj>
solnic: Ducktrap was born before whitequark/ast whitequark/parser. It does currently NOT use the ast lib.
<solnic>
mbj: I will send you a box full of beers if you could tackle sql to a point where I could come back and easily contribute by adding missing stuff
<mbj>
solnic: I think it could be made much better with whitequark/ast internally.
<solnic>
tackle sql and push it to a point*
<mbj>
solnic: hehe, I'll remind you on this.
<solnic>
don't, just send me your shipping address :P
<solnic>
I'm not joking
<mbj>
:D
<dkubb>
make an amazon wishlist with your favourite beers
<mbj>
solnic: I'll send you the shipping addres *after* I had done that stuff :D
<solnic>
lots of awesome polish beers from our finest microbreweries
<mbj>
hehe
<mbj>
I have to visit poland once
<solnic>
no, I want it to be a surprise :D
<mbj>
:D
<solnic>
a list would ruin everything
<snusnu>
they have amazing beer in poland ......
<snusnu>
:p
<mbj>
snusnu: you tasted already?
<snusnu>
yup :D
<solnic>
Martin bought me 30 different beers for my birthday 2 years ago
<solnic>
at a shop downstairs :D
<solnic>
he's pretty much familiar with good polish beer
<mbj>
hehe
<snusnu>
hah right! and you didn't even turn 30 back then :D
<solnic>
yeah, I am this year
<mbj>
solnic: When is your next birthday?
<solnic>
november 18th
<mbj>
solnic: I'll take a note.
<mbj>
I should make a poll where I start working on OSS.
<mbj>
Personally I dont have a that huge preference.
<mbj>
sql, mutant, rom*
<solnic>
from ROM point of view getting sql to work is really important because that's what will enabled people to actually use it; otoh we can continue developing missing pieces using in-memory adapter
<mbj>
solnic: An option for mutant about scope widening would also help.
<mbj>
solnic: Because this is a blocker for you to upgrade.
<solnic>
another benefit of having sql ready is that we could start tacking validations and pushing things down to the db
<solnic>
which might become one of the greatest features of ROM, probably
<mbj>
snusnu, dkubb: Does anyone of you have another blocker in my OSS libs?
<solnic>
btw have you seen that AR plugin which pushes down validations to the db?
<solnic>
mbj: I don't have any blockers
<snusnu>
re sql, it'd be most awesome to generate inner joins, for that, it'd be nice to have Relation#join(other, join_definition, &block)
<solnic>
I'm ok using mutant from my fork, it works for me
<dkubb>
mbj: my only blocker would be a working code filter for mutant
<solnic>
mostly because I can't do it (as in, I don't have that much time)
<mbj>
dkubb: What exactly does it filteR?
<dkubb>
mbj: because then I could add Axiom::Types to the filter in the devtools/mutant config for axiom
<solnic>
oh yeah man, filter for mutant ....that would be great
<snusnu>
the join_definition would basically emulate "the jersey thing" .. defining explicitly on what attributes to join, would remove the need to track renamings for natural join (what we dubbed, the jersey thing back then)
<dkubb>
that's really the only thing I need most from mutant, then I can get back to mutation testing axiom
<mbj>
Filter for the generated mutations?
<mbj>
Or a filter for the code under mutations (subjects) ?
<dkubb>
mbj: you have the --code switch now, which doesn't seem to do anything
<mbj>
dkubb: Yeah 0.3 branch is some kind of broken here.
<dkubb>
mbj: I wondered if you could rename it as --filter, and then have it use the Regexp/Exact match stuff
<solnic>
from my pov sth like that would be sweet: mutant "Virtus*" --rspec --filter "Virtus.warn"
<dkubb>
mbj: I think you have logic now for switching between exact matching and regexp matching for the subject
<dkubb>
ahh yeah
<mbj>
yeah
<mbj>
I have
<mbj>
dkubb: I need axiom-logic
<dkubb>
mbj: it would be awesome to be able to use the same syntax for the exclusion filters as for the inclusion syntax
<mbj>
dkubb: Duplicating it with a stupid predicate system that *works*
<mbj>
dkubb: I allow the same syntax.
<mbj>
dkubb: In latest master.
<dkubb>
mbj: it does? I looked at it and it looks like it's hard coded to use --code for the attribute predicate, which doesn't seem to do anything
<mbj>
dkubb: Okay, lets it say this way: Its prepared to do so.
<mbj>
:D
<dkubb>
it looks like axiom-optimizer is a bit broken after the axiom-types integration, so I'm going to work on fixing that next. shouldn't take too long
<dkubb>
I want to add a couple of really simple optimizations.. like to make it so: relation.nest(:names, [:name]).unnest(:names).equal?(relation)
<dkubb>
or rather: relation.nest(:names, [:name]).unnest(:names).optimize.equal?(relation)
<mbj>
dkubb: Same with ducktrap. I could collaps bodies with one element to the element.
<mbj>
snusnu: If I promise to send you some of the beer I'm eventually receiving, would you create a nice readme for ducktrap? Based on my gist.
<snusnu>
mbj: haha
<mbj>
snusnu: So I'm about to introduce futures ;)
<snusnu>
mbj: no need to send me the beer, i'll just do it
<CraigBuchek>
Is there any documentation on relationships between mappings? I.e. how to specify the equivalent of has_many and belongs_to in ActiveRecord?
skade has quit [Quit: Computer has gone to sleep.]