<snusnu>
the key thing here, is that an axiom schema knows *nothing* about databases, database names, drivers .. *nothing* .. it only knows (base)relations .. the knowledge, which base relations belong to which physical database, is handled elsewhere, axiom-schema basically only supports functional update, allowing you to use #connect to get a "RA compatible" schema instance back, but this time with physically backed relations
lfox has joined #rom-rb
<snusnu>
so you describe your app's schema, and for tests, you might just connect every relation in it to the memory adapter, and in production you might connect some to postgres, some to mysql and some to mongo, whatever
<snusnu>
such an app would define 3 database instances, one for each of the above mentioned databases .. it'd initialize those instances with the respective adapters, and those instances would know a mapping of logical (schema) names, to actual backend base relation names .. when production boots up, it'd transform the (logical) schema into a physical one, with gateway relations for all the 3 databases
<snusnu>
when tests boot up, it'd transform the logical schema into a physical one, with all relations being gateways for the memory adapter
<snusnu>
when it's deployed to a different database, it wouldn't need to change, it'd only need a new database class in your app, that'd know how to "install" the schema on that new backend
<dkubb>
btw, I wouldn't use the logical/physical distinction too much in this context
<snusnu>
yeah, i know, i'm sloppy here
<snusnu>
but i think you know what i mean?
<dkubb>
physical schema, in terms of databases, means the actual filesystem layout
<dkubb>
yeah
<snusnu>
yup, i'm aware of that
<snusnu>
maybe we can use axiom schema and backend schema
<snusnu>
as names i mean
<snusnu>
when talking about it
<snusnu>
or even, relation schema, and database schema
<snusnu>
btw, we can of course easily provide an Axiom::Database class along with subclasses for the supported databases .. you'd instantiate such an instance in your app, and tell it which axiom schema relation (names) it should handle
<snusnu>
and then you use that instance, to retrieve a new schema instance, with the respective relations backed by that database
cored has quit [Read error: Connection reset by peer]
<dkubb>
it's probably bikeshedding, but I'd probably use schema[:people] instead of schema.get(:people)
<dkubb>
this will be consistent with the adapter interface
<dkubb>
one approach I was going to take is have the adapter#[] return any base relations it knows about, which will probably be reflected from the underlying database
<snusnu>
dkubb: yeah of course, #[] instead of #get .. no idea why i used #get, probably because we were talking about *get* on skype, because *[]* is hard to pronounce :p
<dkubb>
heh
<dkubb>
"element reference" is hard to say
<snusnu>
hah, i didn't think about this one even, you know, on skype, we actually talk german ;)
<snusnu>
while in irc (private also) we talk english .. it's funny
<snusnu>
dkubb: when discussing code, english feels more natural, but that only works in a written medium .. when we're actually talking, it's too awkward to not use our mothertongue ;)
<snusnu>
even then tho, we oftentimes have to drop "down to" english ;)
<cored>
hello
<snusnu>
hey cored
<cored>
snusnu: hi
<cored>
I'm also experimenting using [] for instantiation of my collection wrappers
<cored>
found that very pleasent for the eyes
<dkubb>
I like using it for "lookup"
<dkubb>
I use Hash[] sometimes, but I don't find it particularly pleasing
<snusnu>
yeah me too, i even find it weird when used to #call lambdas
<dkubb>
I think of #call and #[] as the same thing when they accept an argument
<snusnu>
i haven't made it that far yet, i'm happy to always call #call by its name :)
<dkubb>
#call is a function that maps some input to some output based on the state of the object you're calling it on
<snusnu>
dkubb: anyways, do you dig the core idea behind that schema api?
<cored>
what do you mean by lookup
<cored>
?
<cored>
like #fetch ?
<snusnu>
cored: array indexing or hash key lookup
<snusnu>
yeah
<cored>
oh
<cored>
maybe it could be confusing having that method to be a factory method
<snusnu>
altho i guess dkubb would extend that definition a bit
<cored>
but I thought that having something like Collection[%w|a b c d|]
<cored>
looks good
<cored>
to instantiation
<dkubb>
snusnu: yeah, I think so. I'll think about it a bit more tonight
<snusnu>
cored: tbh, i'd leave the realm of instantiation to its "natural" habitants .. the likes of new,build,coerce and so on .. but really, it's a matter of taste i guess, not saying one or the other is the right thing to do .. altho it might surprise a few readers of the code, given that instantiation typically doesn't use #[] .. apart from that awkward Hash[]
<snusnu>
dkubb: cool, fair enough
<dkubb>
yeah, I would use .new as the general constructor usually
<snusnu>
dkubb: btw, i locally have functional AST evaluators that construct a complete axiom-schema from an ast already
<dkubb>
I try to keep an interface as natural as I can. you want someone who has not read the docs to be able to read the code and get the gist of what it's trying to do based on the class and method names used
<snusnu>
dkubb: i'll do some *minor* refactorings for it to be inline with that recent idea, and then push it up
<cored>
snusnu: did not think that much, but you are correct on the reading part
jordanyee has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
lgierth has quit [Quit: Ex-Chat]
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
lfox has quit [Quit: ZZZzzz…]
cored has quit [Ping timeout: 264 seconds]
Guest___ has joined #rom-rb
Guest___ is now known as jordanyee
snusnu has quit [Quit: Leaving.]
snusnu1 has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
<postmodern>
mbj, i prefer to coerce so it "just works" tm
<postmodern>
mbj, but really everything get's converted down to Strings before being executed
<mbj>
postmodern: I dislike this kind of bugs that occur with implicit coercions.
<mbj>
postmodern: the caller should provide type compatible values. If not raise.
<mbj>
postmodern: Checking types can easily be dslified.
<mbj>
my 2¢
<mbj>
Will happily play around with your new wrapper once ready ;)
<mbj>
postmodern: Is you wrapper able to capture both, stderr and stdout?
<postmodern>
well i never got around to finishing the complex logic that converts all the attributes to [option, *values] lists, but also could run them through Shellwords.shelljoin
<mbj>
postmodern: you need a structured type mapper like ducktrap for this ;)
<postmodern>
so it's kind of moot to debate about the design of the code
<mbj>
heh, np lets stop and focus on stderr and stdout
<mbj>
what if stderr and stdout are in "sync" mode. Means they need to be consumed before writer can write again.
<mbj>
How do you "read from both" at the same time without blocking / running into a deadlock.
snusnu has joined #rom-rb
<mbj>
I have some code in a simillar wrapper that usese select.
<mbj>
*uses select
<mbj>
To make sure I dont do a blocking read on stderr, while there is only data on stdout (and vice versa).
<mbj>
snusnu, going to sleep, sorry will read that pastie tomorrow