<dkubb>
snusnu: I would probably have something like url_params and body_params (with better names of course)
<dkubb>
snusnu: it doesn't matter the method that was used to send them, what matters more is where they are being used
<dkubb>
snusnu: often the logic for using url_params is different from body_params.. you'd use the former for routing, and maybe for some query generation for scoping, while the latter is usually used to create or update a resoruce
<dkubb>
*resource
<snusnu>
dkubb: exactly my thoughts yeah … so i wonder, are there better names ;)
<snusnu>
dkubb: #query #content maybe?
<snusnu>
dkubb: or Input#{actor, query, state}
<dkubb>
snusnu: hmm, good point.. what about path_params, query_params for the URL based stuff?
<dkubb>
snusnu: parameters inside the path are often used for scoping, query params are used for searching (usually)
<snusnu>
dkubb: ah, good point re splitting scope vs. search
<snusnu>
dkubb: fwiw, my reasoning behind #query was that both scoping and searching boil down to some sort of query, while post params are usually used to perform a command (somewhat equivalent to how we use command query separation)
<snusnu>
dkubb: what if we just go with #query and #command … is that too abstract?
<snusnu>
dkubb: so: Input#{actor, query, query?, command, command?}
<snusnu>
dkubb: hmm, doesn't *really* fit, but i somehow like it
<dkubb>
snusnu: I see path, query and message body being different things usually
<snusnu>
dkubb: btw, i'd expect both #query and #command to be "destructured" already .. so you'd get input.query.id and input.query.conditions maybe … and input.command would probably point to some sort of dto
<dkubb>
I think command is a bit more abstract
<dkubb>
s/more/too/
<snusnu>
hm yeah
<dkubb>
HTTP really is about message passing
<dkubb>
you pass a message body with your request
<snusnu>
good point
<dkubb>
the URL identifies the resource, and the message body contains the data applied by the method
<dkubb>
I kind of would like it if web frameworks separated the resource lookup from the message application
<snusnu>
dkubb: btw, the names i'm trying to find aren't strictly tied to http anymore .. they are what should enter the system after it doesn't even have an idea about the fact it's called via http
<dkubb>
if you could somehow specify how the URL maps to the resource, and the resource is loaded from the datastore, and then it invokes the method on it with the body as an argument
<dkubb>
ahh I see
<dkubb>
well, it could probably work if you separate resource resolution from the message receipt
<cored>
uff, kinda tire will have a nap
<cored>
will come later
<snusnu>
dkubb: well, with substation you absolutely get this separation, afaics … then again substation is no webframework, but imo no webframework is needed ;)
<dkubb>
the URL kind of identifies the inbox, and then you deliver the message to it
<dkubb>
(if you want to think of it a different way)
<snusnu>
yeah, i see how that's a nice way of looking at it
<snusnu>
so basically the query/search - GET params are dispatcher info, finding the resource to either pass a message body to, or just invoke it as a query
<dkubb>
yeah, the url maps to the resource, then you do resource.public_send(method, message_body) effectively
<snusnu>
but tbh, i don't think that much in "resource" terms .. i think about it as method dispatch i guess .. finding the object to send a message to
<dkubb>
I would love it if a web framework did: response = resource.public_send(method, message_body); resource.negotiate(client.accepts)
<dkubb>
in psuedo code
cored has quit [Ping timeout: 276 seconds]
<snusnu>
dkubb: with substation you pretty much get that first part, altho there's a dispatcher plugged in between, so that you can implement the use case in a dedicated class responding to #call, while still be able to give it a name .. this greatly helps with SRP .. because you can move out all the other typical stuff (deserializing, sanitization, auth(z), validation, USE_CASE, presenting, serializing/rendering) into dedicated classes too
<snusnu>
dkubb: that separation leaves you with very tiny classes, that are very very easy to test
<snusnu>
dkubb: once the chain hits the pivot, i typically interact with my business logic classes, which use dto's to communicate with the db (using dm-mapper)
<snusnu>
dkubb: so i guess i don't have that "resource" concept, but i don't miss it
<snusnu>
dkubb: so a typical substation app is "just an app" .. if you stick webbish incoming/outgoing handlers around the pivot (the use case) .. it turns into something fit for a web app
<snusnu>
dkubb: if you then plug that behind rack and a router, you're all set
<snusnu>
dkubb: so, substation really doesn't care how you structure your actual app (the business logic, no web) .. as long as you expose its public api via objects that respond to #call
<snusnu>
dkubb: i find that better than sticking all people related methods into a PersonResource class or something like that … i always hated how in rails, all the methods to manipulate a resource, are inside a single class
<snusnu>
dkubb: initially, substation started out as some sort of rails plugin that defined methods like PeopleController#index and have it instantiate and invoke some People::Index class
<snusnu>
dkubb: then i ditched rails …. ;)
<snusnu>
dkubb: i guess substation also encourages the architecture layed out by robert martin at some point .. plus it adds the chain of responsibility pattern to facilitate typical webbish parameter transformation and response preparation
<snusnu>
dkubb: so yeah, i'm quite happy with it so far, as you might have noticed ;)
<dkubb>
yeah I need to give it a spin for something small to get the hang of it
<snusnu>
dkubb: just one more thing, then i'll shut up: i also had in mind specifically, that i want to be able to build the "core" application using substation api .. and that i'm able to test it easily .. it should no nothing about it's clients, it should just expose an oo api .. i wanted to then be able to plug that app into different "clients" .. say, a cli app, a web app that returns html, one that returns json … all the time using the co
<snusnu>
dkubb: heh awesome
<snusnu>
dkubb: so e.g my core app expects Input#{actor, data} .. then does authentication and validation (not devise like, oo like) .. and then invokes the usecase, something like CreatePerson#call(actor, person)
<snusnu>
dkubb: probably some trickery could even get me to invoke PersonResouce#create(actor, person) .. probably wouldn't be that hard
<snusnu>
dkubb: but even then, i'd expect to have PersonResource#create actually instantiate and invoke CreatePerson#call
<snusnu>
dkubb: but tbh, i don't like that very much, i'm happy having a class for a usecase, seems fitting .. also makes for a nice directory/file listing/browsing to get an idea of what one can do
<dkubb>
snusnu: I'm thinking abotu ways to clean this up, maybe with an explicit Schema object
<dkubb>
I could have it so when I assign a base relation to schema#[]= it wraps it in a gateway, since it could know the adapter it belongs to
<dkubb>
I just am not sure yet if it's going to be the behaviour we want 100% of the time. I think it is, but I don't know
<dkubb>
snusnu: what I plan to do on the RDBMS side is reflect on the db and populate the default schema object
<snusnu>
dkubb: do you plan to scope a schema to a specific adapter? (asking because you do schema = adapter.schema and because you said the schema would know the adapter the base relation would belong to)
<snusnu>
dkubb: i was actually thinking a schema is just a collection of gateway relations, each having whatever adapter
<snusnu>
dkubb: or a collection of relations for that matter, as they quack the same .. no adapters involved
<snusnu>
dkubb: i imagined to have one schema for an app .. that might "span" multiple adapters
<snusnu>
dkubb: so, a schema would simply be a registry of relations, some of them might be gateways using whatever adapter, some of them might be raw axiom relations
<snusnu>
dkubb: in any case, i find it very awesome that the stuff you pastied works!
<snusnu>
dkubb: altho i wonder if "raw axiom relations" makes any sense .. i'd expect a schema to be persistent (to some degree) i.e. "at least" use the in-memory adapter
<snusnu>
dkubb: from rom-mapper's pov, it wouldn't need to make any distinctions anyway, so it'd be cool if we could just get at some postgres relation and a mysql relation, and just join those .. by "get at some", i mean asking an object to hand back those previously registered relations .. and by an object, i guess i meant that schema
<snusnu>
dkubb: s/rom-mapper/rom-relation above
<snusnu>
dkubb: rom-mapper doesn't care at all
<snusnu>
dkubb: the dsl i suggested recently, exposed #base_relation which yielded an instance_eval'ed block that exposed #repository .. thus setting the adapter
<snusnu>
dkubb: so i assumed that our schema will span multiple adapters/repositories with that dsl
<snusnu>
dkubb: i dunno, maybe it'd still make sense to have adapter specific schemas, and have some different object "wrap" those schemas, thus making access transparent?
<snusnu>
dkubb: and of course, maybe you have a very good reason to have the schema adapter specific … i guess i'm done with my points anyways ;)
<dkubb>
snusnu: no, this is good feedback. I think I'm leaning in your direction
<dkubb>
snusnu: I'm still trying to decide if there'll be a 1:1 relationship between the adapter and schema, and/or if there'll be something larger that aggregates them
<dkubb>
bbiab
dkubb has quit [Quit: Leaving...]
therabidbanana has quit [Quit: leaving]
dkubb has joined #rom-rb
machuga is now known as machuga|away
therabidbanana has joined #rom-rb
dkubb has quit [Quit: Leaving...]
dkubb has joined #rom-rb
dkubb has quit [Client Quit]
dkubb has joined #rom-rb
snusnu has quit [Quit: Leaving.]
dkubb has quit [Quit: Leaving...]
dkubb has joined #rom-rb
zekefast has joined #rom-rb
theCrab has joined #rom-rb
zekefast has quit [Quit: Leaving.]
solnic has joined #rom-rb
<solnic>
dkubb: morning
<theCrab>
morning y'all
<dkubb>
solnic: good morning
<solnic>
dkubb: saw some awesome progress on the memory adapter
<dkubb>
solnic: I almost have a memory adapter ready, just tweaking and rearranging stuff
<solnic>
haha. right
<solnic>
so yeah, just wanted to ask how far you are with it, looks like quite far :)
<dkubb>
solnic: I got it working earlier today. I wasn't happy with the organization yet, so just trying a few different things
<solnic>
gotcha
<solnic>
I'm gonna try it out in rom-relation and session then
<dkubb>
solnic: I had today for oss since I finished a project yesterday. I think there's a new one tomorrow or friday, but I'm going to work on the memory adapter until it starts
<dkubb>
k
<solnic>
that's cool
theCrab has quit [Quit: Sleeping -_-]
therabidbanana has quit [Quit: leaving]
zekefast has joined #rom-rb
<dkubb>
solnic: I have a local fix coming that will allow this to work: http://pastie.org/private/wvdognknibjrpwqrybqia .. this is simplified from the one I pasted earlier today and discussed with snusnu
<solnic>
dkubb: oh wow this is nice
<dkubb>
solnic: ok, I think I'm going to leave the PR until tomorrow. I want to get mbj's and snusnu's input too
<solnic>
dkubb: ok :)
<dkubb>
the adapter api really is only important to the gateway. it *can* vary, but I would like to find something that fits 90% of the use cases, and for that I'd like to get mbj's input since he's written more adapters than anyone else
<dkubb>
the gateway is really the most important piece. it cannot vary in terms of it's public interface. internally it can do whatever it wants
<solnic>
sounds about right
<dkubb>
ok, I think I'm going to hit bed now
<dkubb>
solnic: good night!
<solnic>
dkubb: nite :)
zekefast has quit [Quit: Leaving.]
postmodern has quit [Ping timeout: 240 seconds]
postmodern has joined #rom-rb
solnic has quit [Quit: Leaving...]
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
solnic has joined #rom-rb
mbj has joined #rom-rb
machuga|away is now known as machuga
snusnu has joined #rom-rb
zekefast has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
solnic has quit [Quit: Leaving...]
machuga is now known as machuga|away
postmodern has quit [Quit: Leaving]
mbj_ has joined #rom-rb
mbj has quit [Ping timeout: 240 seconds]
solnic has joined #rom-rb
machuga|away is now known as machuga
theCrab has joined #rom-rb
snusnu has quit [Quit: Leaving.]
cored has quit [Ping timeout: 248 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
<cored>
hello
<cored>
do you gyus know if active record supports table per class hierarchy ?
snusnu has joined #rom-rb
solnic has quit [Quit: Leaving...]
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
solnic has joined #rom-rb
zekefast has quit [Quit: Leaving.]
<Gibheer>
cored: you mean for every class inheriting from another model?
<Gibheer>
activerecords builds a table for every model I think
<Gibheer>
at work they used that and created a huge amount of tables all referencing a single table :/
<cored>
wow
<Gibheer>
why are you interested in that?
<cored>
Gibheer: a friend told me that he will stop programming in Ruby because is bad and also Rails and state that regarding AR
<cored>
I was just wondering if there's exist someting like that ;-)
<Gibheer>
it is the same mess in most languages :/
<Gibheer>
rom is different, but will take some time to finish though
<snusnu>
cored: i'm almost certain that AR has no builtin support for class table inheritance .. because, well, it is an active record, i.e. it maps a row in the db into an object .. class table inheritance by design requires more than one row from more than one table .. that's no business for an AR
<snusnu>
cored: that said, this ain't a shortcoming from active_record the gem, but the pattern itself .. ruby,java,dotnet, whatever
<snusnu>
cored: fwiw, with rom you will be able to do that easily
<snusnu>
cored: i hope i didn't confuse you btw, the article you linked talks about single table inheritance, something that active_record supports (as does dm1 and obviously rom will too)
<dkubb>
snusnu: I'm not sure if it will be easy, but I think it will be possible to support CTI
<snusnu>
dkubb: yeah, easy might be the wrong word .. it will be easy for rom users to do CTI .. we as rom authors will probably have to think about it a bit more ;)
<dkubb>
conceptually I prefer CTI to STI. instead of having a single wide table with a bunch of possibly NULL columns to support every possible STI subclass, you have multiple tables, each with just the attributes each model uses. when fetching records for a model you join just the tables you need
<dkubb>
snusnu: I think the axiom writable join stuff will help make it possible.. reads are pretty easy to support, it's writes that are harder
<dkubb>
snusnu: we can easily make a mapper that has a join relation now. it's when someone wants to insert, update or delete from it that it gets a bit complex
<snusnu>
dkubb: yeah, imo STI is a good fit only if the hierarchy doesn't differ in state, but behavior mostly .. i'd almost NEVER want to introduce a nullable column for the sake of mapping the hierarchy into a single table
<snusnu>
dkubb: yup, i agree
<dkubb>
snusnu: ahh yeah, if the subclasses are identical in terms of attributes and you're just using the different classes to represent a different state of the object or something STI works
<snusnu>
dkubb: and granted, i was mostly thinking about reads as i wrote my comments
<dkubb>
snusnu: the problem is that's really a rare case (IME)
knowtheory has joined #rom-rb
<dkubb>
when I use STI the models always begin to drift
<snusnu>
dkubb: heh yeah, i've seen that too
<cored>
does rom will have an identity map implementation ?
<snusnu>
cored: yes
<dkubb>
I would guess it'll be in the session part
<cored>
nice
<dkubb>
a session usually manages an IM
<cored>
so we need rom-rb asap
<cored>
:-)
<dkubb>
yeah, there's definately a need for it
<cored>
but there's no finishing date at the moment, right?
<dkubb>
no
<cored>
I guess the best approach after something done it's to get some documentation with actual apps build with it
<dkubb>
it doesn't work for oss projects unless the project is being funded by a third party
<cored>
I see
<dkubb>
because everyone works on it in their own time, you can't mandate that volunteers deliver by a specific date
<dkubb>
you can set deadlines for yourself, but it doesn't work for a team effort imho
<cored>
either way you guys have a roadmap, right?
<Gibheer>
like my boss said, I had to get my project ready in one month and I can't use rom because of that :(
<dkubb>
yeah
<cored>
Gibheer: but he said that because is not yet released, right ?
<Gibheer>
no, it was my choice to choose an ORM
<cored>
dkubb: so when all the main goals get done, release?
<Gibheer>
and I tried for half a day to rescue over my work from the beginning of the year with DM2, but it just did not work anymore
<cored>
Gibheer: shame, so are you using AR ?
<dkubb>
cored: yeah, we'll start the release process once the pieces are done.. of course by the time that happens each of the pieces will probably have been in release for a while
<dkubb>
cored: we'll likely iterate for a while to get all the pieces right
<Gibheer>
cored: no, I will use sequel
<cored>
I see
<cored>
Gibheer: why ?
<cored>
dkubb: great, sounds good
<Gibheer>
it feels right and is more like rom than ar
solnic has quit [Quit: Leaving...]
<cored>
Gibheer: just to see if it's solve some of AR problems
<cored>
Gibheer: the thing is Rails integration
<Gibheer>
and in the worst case, I can construct SQL myself to get what I need
<Gibheer>
I don't care about rails, it is too big
<dkubb>
it's good to test out the other ORMs
<Gibheer>
I have build my own stuff to get rendering and routing working, so I don't need rails
<Gibheer>
I don't need all the features, it just has to take request and render the response, so sequel fits perfectly into that
<dkubb>
Gibheer: are you using sinatra or something?
<cored>
Gibheer: isn't that more problematic to maintain?
<Gibheer>
dkubb: no, I use my own small collection named zero
<Gibheer>
cored: where would it be more problematic?
<Gibheer>
no, that is the wrong question
<Gibheer>
where do you see problems of maintaining it?
<dkubb>
I think rails probably does too much
zekefast has joined #rom-rb
<dkubb>
I would prefer to see rails broken up into smaller reusable pieces. it's still all or nothing in some sense
<cored>
Gibheer: more code you have to maintain and worry about
mbj_ is now known as mbj
<cored>
dkubb: I thought that was what the merb merge will do, but in the end it was just some small stuffs from there and put it back into Rails
<Gibheer>
cored: actually, it is much less code I have to maintain
<dkubb>
cored: yeah that was unfortunate
<cored>
Gibheer: also I'm checking Sequel documentation it's looks like more or less as AR, maybe I'm wrong but it's looks like a table map to a class as in AR if you use the Sequel::Model stuff, I was wondering if there would be some sort of repository which I can switch from in memory to actual database so I can test in isolation from my persistence layer
<Gibheer>
I tried rails some time ago and I just did not understand how it works. So I went into the code and followed it through to understand, what it is doing and it is just too much code and too much magic
<Gibheer>
yeah, in that aspect, it is like AR
<Gibheer>
could not find a way to specify my model like in ROM yet, but at the moment, it is low in the priority list
<Gibheer>
I also tried padrino, but had problems with the upgrade path every time and sinatra is very nice for very small stuff, but gets weird when the project gets larger
<dkubb>
Gibheer: Sequel has two components, the core and the model. the model has a DSL I think
<Gibheer>
seeing how dm2 evolved, I thought I could build something small like sinatra myself with a cleaner approach, so I did and it is pretty nice
<dkubb>
I would like to see form helpers extracted into something that is not framework specific
<dkubb>
Gibheer: have you used devtools or mutant with zero?
<Gibheer>
I used mutant, yes and we found some bugs with it
<Gibheer>
but I did not get devtools working
<Gibheer>
mbj knows about it and tried to help, but somehow I did not get warm with it
<dkubb>
fwiw, I just started using devtools on a rails project and I made some modifications to it
<dkubb>
Gibheer: yeah, it does require some configuration to find the right settings. I think having thresholds in place helps a project stay on track quality-wise.. at least better than having to be vigilant solely on your own
solnic has joined #rom-rb
<Gibheer>
dkubb: I will see how this project will work out. I have no programmers around me to help, only ops guys so introducing them into testing is a huge amount of work in itself
<Gibheer>
I did that with every shell script till now and every time someone deleted the tests ...
<Gibheer>
so I will use rspec to do the tests and will try to have a high quality, but I don't know how long that will work :/
<cored>
the need for rom increases :-)
<Gibheer>
cored: yeah, that would have helped much in forcing them to read the code *g*
<cored>
dkubb: devtools, that was one of the things I told mbj. How can I make it easy to use in any project
<dkubb>
cored: I think it gets easier the more we try to use it on different projects
<cored>
dkubb: I have this small lib is a wrapper for bitbucket API
<cored>
dkubb: I wanted to try there, was kinda hard in the end I decide that at first glance the code is a mess and I want to re-write haven't take the time to start with it. But I would love to use devtools or at least mutant
<dkubb>
cored: one thing devtools helps with is making sure code quality doesn't decrease without you knowing about it. you can configure all the thresholds so they match the current code, and then gradually improve them as the project quality increases
<dkubb>
cored: for me, it helps to have something constantly checking the code in the most pedantic way possible. I'm pretty pedantic myself, but I can't compete with a tool
solnic has quit [Remote host closed the connection]
<cored>
:-)
<cored>
I will try it again
<cored>
on the current code
<cored>
maybe I can do some refactor to it and not just throw everything away, maybe devtools can guide me to the right direction
<dkubb>
the main thing is not to follow everything it says, it's to try to understand why it flagged the code and use that to think about alternatives
<dkubb>
I know some people who dismiss the warnings and just update the config on the first sign of a problem
<cored>
he
<dkubb>
but the majority of the stuff it flags is pretty accurate imho
<dkubb>
the best part is that if you use it as a learning experience it'll help you learn new ways of refactoring and structuring the code that are probably better than what you're doing now
<cored>
refactoring?
<cored>
probably pointing me out where the problems are, but the refactoring technics I will have to learn it by myself
<dkubb>
yeah, but what I mean is that it gives you some pointers but you're responsible for following up on them
<dkubb>
for example, if you've never heard of Feature Envy and reek tells you it thinks one of the methods exhibits feature envy, then you can do the research to find out what it means and you become better at catching it next time
<dkubb>
if you just follow it blindly it won't be as good an experience as if you use it to further your learning
cored has quit [Ping timeout: 268 seconds]
therabidbanana has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
solnic has joined #rom-rb
<solnic>
cored: we can't talk about dates because everybody is working on rom during free time
<solnic>
which is very ad-hoc
<dkubb>
there's enough guilt involved in oss development that if we make it worse people will drop out altogether ;)
<mbj>
dkubb: so true
<snusnu>
cored: since you asked a while ago .. i refactored the substation integration spec app into separate files .. if you're interested (or really, anyone else too) .. here's what it looks like now (it will still be simplified/improved, but yeah): https://github.com/snusnu/substation/tree/decompose-compose/spec/demo
<snusnu>
particularly, both core and web apps will get their own environment eventually, but i need to add support for building on top of existing environments, before that
solnic has quit [Quit: Leaving...]
<snusnu>
mbj: i've decided to more or less move substation-demo into substation integration specs .. this forces me to keep it uptodate ,)
<dkubb>
I can't believe delete and insert propagation works this nicely
<dkubb>
this is equivalent to the writable views problem that rdbms face
<snusnu>
dkubb: yeah this is srsly awesome! what are the limits of writing to "composed" relations?
<snusnu>
dkubb: i assume there are some? otherwise it'd be too great i guess :p
<dkubb>
snusnu: yeah, not all relations can propagate writes
<dkubb>
snusnu: and there's stuff where if you join a model to itself
<dkubb>
snusnu: if you project away some columns you can't write to a relation anymore either, assuming those columns are required
<snusnu>
dkubb: ok that makes sense, essentially you'd try to write "incomplete" tuples
<dkubb>
exactly
<snusnu>
dkubb: so i wouldn't call that a limitation, it's obviously just not possible, "composed" relation or not
<dkubb>
yeah, right
<snusnu>
dkubb: also, i wouldn't expect that to be a problem .. as soon as you project away, you're probably doing some sort of "reporting" (in the abstract sense) .. like a query method, not a command one
<dkubb>
if you had a default value for an attribute I think it could be made to work, but I don't recall doing anything around that
<dkubb>
that's exactly right
<snusnu>
dkubb: so what are the cases apart from those "attribute reducing self joins"? e.g what happens when a relation got extended?
<snusnu>
dkubb: i guess the extensions could be thrown away silently? or would that need to fail for some other reason?
<dkubb>
snusnu: I thought about what you said about wanting a schema that mixes gateways from different sources, and I think that's a nice approach. I decided to have methods on the adapter for fetching and storing the relations: https://github.com/dkubb/axiom-memory-adapter/pull/1 .. we can then make a schema on top of it that routes a given name to the expected adapter and named relation
<snusnu>
dkubb: yeah, i thought that you had something like that in mind, i like it
<dkubb>
I'm fairly happy with the code, I just need to do some testing with axiom-fuzzer and get mbj's input
<dkubb>
snusnu: why's that?
<dkubb>
snusnu: the fact that if you probe the adapter without knowing the name it'll blow up?
<snusnu>
dkubb: by weird, i mean, the method is called #[] yet calls fetch internally .. i somehow wouldn't expect to see an IndexError when calling #[] .. granted, the adapter isn't really a hash interface .. but yeah, i noticed the #[] #fetch thingy
<snusnu>
dkubb: yeah
<dkubb>
snusnu: yeah, I thought about that. I may add one more method to test if the relation exists
<snusnu>
dkubb: or maybe raise at least some custom error?
<snusnu>
dkubb: from inside fetch's block
<dkubb>
yeah, maybe raising something customer is better then an KeyError
<dkubb>
*custom
<snusnu>
right, it's KeyError .. was IndexError tho? 1.8.7?
<snusnu>
dkubb: KeyError kinda implies it's a hash interface, which it actually isn't .. well, not really at least
<dkubb>
yeah, I could raise UnknownRelationError or something
<snusnu>
yup
<dkubb>
yeah, I'll do that
<dkubb>
I don't mind #[] being strict
<snusnu>
dkubb: apart from that, it's absolutely beautiful how little code was needed to do the in-memory adapter
<dkubb>
in most interfaces, given a #[] and #fetch I use #fetch 99% of the time
<dkubb>
that's why I figured I might as well make #[] strict
<snusnu>
dkubb: yeah me neither, i use #fetch too whenever i can … it's only in the context of dealing with a hash, that i'd be kinda surprised if #[] were to raise
<snusnu>
dkubb: yeah, i see the reasoning .. it's not really a hash
<snusnu>
dkubb: but yeah, a KeyError would still be kinda surprising .. #[] is fine tho
<snusnu>
dkubb: being strict and all
<snusnu>
dkubb: one could also argue that raising a KeyError would needlessly expose an implementation detail, which might not be obvious to everyone, someone might just be surprised and expect a hash like interface
<snusnu>
dkubb: that is, if ThreadSafeHash raises KeyError in #fetch .. which i would guess it does
<dkubb>
yeah it does
<dkubb>
I will make it raise something adapter specific
<dkubb>
it is unnecessarily exposing a detail. I don't want to expose I'm using a Hash under the hood
zekefast has quit [Ping timeout: 268 seconds]
<dkubb>
snusnu: do you think it would be weird to have UnknownRelationError = Class.new(KeyError) or do you think or should inherit from IndexError or just StandardError?
<dkubb>
keep in mind KeyError inherits from IndexError
<dkubb>
I like when my own code raises custom exceptions, but I also kind of like to find the most precise class from stdlib to inherit from
<snusnu>
dkubb: heh yeah, i know that question ;)
<snusnu>
dkubb: tbh, recently i went with just inheriting from StandardError .. for the same reasons mentioned above, inheriting from some builtin exceptions kinda implies a specific form of implementation imo .. like with Index/Key Error .. that might sometimes not be appropriate
<snusnu>
dkubb: there are other exceptions tho, like ArgumentError, where that decision is not that easy
<dkubb>
yeah
<dkubb>
although IndexError doesn't seem to be implementation specific
<dkubb>
both Hash#fetch and Array#fetch raise it (or subclasses of it)
<snusnu>
dkubb: yeah, i guess i know what you mean .. the name is "generic" enough to be useful and intention conveying in lots of other cases .. yet somehow, i still relate it to hash and arrays mostly, both being concepts i (at least sometimes) want to hide, by writing a new class in the first place
<snusnu>
dkubb: all that said, i guess i don't have a strong opinion .. i just know that i was thinking about that very same thing a few times before already .. like you :)
<snusnu>
dkubb: it's probably "better" to "reuse" the *name* tho .. and not tie it to specific ruby (stdlib) occurences mentally
<dkubb>
I think I'll probably use IndexError as a base class for now, but I will raise UnknownRelationError.. it feels better than ArgumentError
<dkubb>
yeah I would mostly encourage UnknownRelationError
<dkubb>
I just read the description for ArgumentError and it says "Raised when the arguments are wrong and there isn't a more specific Exception class." .. this seems like it's kind of a catch-all, but that something more specific should be preferred
<dkubb>
of course I could just be projecting
<snusnu>
dkubb: btw, have you *ever* looked at the inheritance hierarchy of an exception thrown at you? i actually don't remember one single time i guess … the name of the exception must be fitting, then i'm happy
<snusnu>
dkubb: sounds reasonable tho
<dkubb>
snusnu: I haven't. but then again I sometimes do widen the net and catch whole classes of errors when debugging
<snusnu>
dkubb: cool, and again, the in-memory adapter code is beautiful, so little work needed
<dkubb>
thanks
<dkubb>
it's almost as simple as the dm memory adapter
<dkubb>
except way more powerful
<snusnu>
heh yeah
<dkubb>
since most of the actual logic to perform the operations is in each relation subclass
<dkubb>
this code is mostly just about persisting it
<dkubb>
I used ThreadSafe::Hash to force all reads and writes to be serialized
<snusnu>
dkubb: yeah, the gateway is almost unbelievably simple
<snusnu>
dkubb: sounds like a fair thing to do, proactively
<dkubb>
in MRI it's just a ::Hash, in JRuby and rbx it does other things, since they have no GIL and the Hash can actually be modified by different threads
<snusnu>
ah ok, cool, we'll be deploying to jruby soon :)
<dkubb>
I was going to use Mutex and do it myself, but when I saw headius wrote a gem for it I figured it was better than what I could do
<snusnu>
well, we probably won't deploy the in memory adapter to production, but yeah ;)
<dkubb>
even Rails 4 uses this gem too
<dkubb>
haha
<dkubb>
snusnu: postgresql?
<snusnu>
yeah
<dkubb>
nice
<dkubb>
that's my primary target now
<snusnu>
yeah, altho tbh i'm no pro at all, it seems to be the best relational oss alternative
<dkubb>
postgresql gets the attention first, then I will port the stuff to the other dbs as time allows
<snusnu>
sweet, i kinda knew that already, but it's reassuring :)
<dkubb>
all my new projects are pg. I may take on some mysql rescue projects, but will probably change them to use pg too
<dkubb>
if possible of course
<snusnu>
it's actually only my 2nd project on pg, then again, i do very few projects altogether :)
<snusnu>
dkubb: lol, guess what i just witness … if i have the same, EMPTY module included in 2 classes, my flay score is 160 .. if i *remove* that module inclusion, flay bumps up to 172
<dkubb>
heh
<dkubb>
I bet the extra code made your code less similar to other places
<dkubb>
then you removed it, and the code was more similar
<snusnu>
dkubb: hah!
<snusnu>
of course
<dkubb>
I get hit by flay all the time because I try to be consistent in my code layout
<dkubb>
and naming
<snusnu>
i always get it wrong, thinking flay is complexity
<dkubb>
nah, it's similarity
<snusnu>
right
<dkubb>
all things being equal it's not the most important metric to me
<dkubb>
complexity is
<snusnu>
yeah
<dkubb>
I can deal with a few classes that are roughly the same
<snusnu>
best measured by nr of mutation :)
<dkubb>
but I can't deal with gigantic classes or methods
<snusnu>
yeah
<dkubb>
yeah I think of mutations as the number of possible ways I can fuck up a given expression
<snusnu>
a good case for my recent module class PR .. better to see the similar code, than to have more complex methods
<dkubb>
the goal in the end is to have no more generic nodes, and for every node to have an explicit mutator
<dkubb>
I was thinking about contributing one node handler per week or something
<dkubb>
even if it's dead simple, like replacing the node with nil or something
<snusnu>
yeah, i've followed that discussion .. while i'd love to contribute to mutant too, i currently like substation best (and need it the most .. it's actually extracted/guides our app)
<dkubb>
yeah
<dkubb>
what I was more thinking about was recruiting people outside of the 4 of us to help with this
<dkubb>
there's tons of peolpe who want to help, and these are low hanging fruit
<dkubb>
while it's hard for people to contribute, say rom-session, writing mutations is simple and helps everyone
<snusnu>
sounds like a plan yeah, some might need a bit convincing that while it may sound complicated, it probably isn't that complicated after all
<dkubb>
to work on the core rom stuff you have to be familiar with the whole stack which isn't realistic for someone new to the effort
<snusnu>
yeah, it can be a bit daunting
postmodern has joined #rom-rb
<snusnu>
otoh, imo it's a matter of days to get roughly familiar with the stuff .. then again, not everyone has the privilege/problem to spend (subsequent) days on that stuff
<dkubb>
even still I think it is hard to jump into that stuff because we've had so many decisions on the direction
<snusnu>
yeah, after all, the code is already years in the making .. taking everything into account .. being familiar with that domain might blind us from seeing how difficult it might look for outsiders
<snusnu>
maybe it's somewhat similar to what we think of code written in a different style nowadays … it feels hard to contribute to ;)
<dkubb>
yeah
<dkubb>
but it's easier for us to maintain
<dkubb>
and really, given my experience with DM, we're better off making it easier for us and harder for contributors than the other way around
<dkubb>
if we have to choose of course
<snusnu>
i fully agree with that
<dkubb>
because in the end we'll still end up doing 95% of the work
<dkubb>
unless someone else is lucky enough to get their company to sponsor full time work
<snusnu>
yeah
<snusnu>
and you know what, i, and i'm sure all of us, actually do it mostly for fun, and because we want to improve ourselves … working on oss is always somewhat egoistic too :) ..
<dkubb>
I'm convinced that most really successful oss projects either have corporate sponsorship, or someone is seriously sacrificing to make it work.. which I think gives oss users a skewed perception of how things actually work
<snusnu>
yeah, i think so too
<dkubb>
you know what though, there's more barrier to entry with ROM, but there are more peolpe working on ROM than when DM was at it's peak in terms of contributors
<dkubb>
I also haven't heard too many people who were like "you know, I tried to submit a patch but your metrics tools kept screaming at me so I gave up"
mbj has quit [Quit: leaving]
<snusnu>
that's true yeah, and tbh, i'm constantly surprised why we don't get even more contributors .. it's *such* a valuable project for the whole community .. but yeah, as you said, i don't believe that our rules and principles are the reason for that
cored has quit [Ping timeout: 240 seconds]
mbj has joined #rom-rb
mbj has quit [Ping timeout: 276 seconds]
<snusnu>
dkubb: btw, i was wondering what you are planning to tackle next after the in memory adapter?