<dbussink>
solnic: but that will potentially affect performance pretty heavily if you freeze every string coming out of a database etc.
<dbussink>
because of a global lookup table and gc pressure it causes
<solnic>
dbussink: we don't freeze stuff that we fetch from the db
<solnic>
it's up to you what kind of objects YOU want to build
<dbussink>
solnic: ah ok, i thought that was what you meant
<solnic>
no, I meant that our internals are immutable
<dbussink>
solnic: well, question would be, do you freeze a lot of stuff at runtime that is not a somewhat persistent string?
<solnic>
define a lot :)
<solnic>
all relations are immutable
<solnic>
so every time you do something on a relation you get a new relation back
<solnic>
relation names are symbols
<dbussink>
solnic: just wondering about whether a change like that would have an impact on use cases like rom does
<dbussink>
if that would be a real concern or not
<solnic>
not sure, really, we avoid strings fwiw
bf4 has joined #rom-rb
breakingthings has joined #rom-rb
bf4 has quit [Ping timeout: 248 seconds]
bf4 has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
bf4 has quit [Ping timeout: 248 seconds]
CraigBuchek has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]
knowtheory has joined #rom-rb
knowtheory has quit [Ping timeout: 252 seconds]
bf4 has joined #rom-rb
knowtheory has joined #rom-rb
bf4 has quit [Ping timeout: 248 seconds]
mbj has joined #rom-rb
zekefast has quit [Quit: Leaving.]
cored has quit [Ping timeout: 260 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
skade has quit [Ping timeout: 248 seconds]
zekefast has joined #rom-rb
dkubb has joined #rom-rb
<dkubb>
good morning
zekefast has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<dkubb>
snusnu: hola
<snusnu>
hey dkubb
<mbj>
dkubb, snusnu: Still busy ;)
<mbj>
17.10 is the start of my OSS weeks ;)
<dkubb>
hah
<snusnu>
mbj: heh ok
<mbj>
The day of my flight to kenya.
<snusnu>
nice
<dkubb>
I started late today so I will only be lurking here anyway
<dkubb>
going to do some more nest/unnest stuff tonight. I should make some good progress I think
<snusnu>
sweet!
<dkubb>
I think it may be ready for testing a bit
<mbj>
dkubb: I'd love to assist. But *busy* blocked....
<dkubb>
no worries
<mbj>
so much OSS conversation / work that had queued up
<snusnu>
i'll be pretty busy until friday too .. but i'd love to experiment with nest/unnest a bit during the weekend
<snusnu>
with that, and ducktrap
<mbj>
snusnu: Heh you are becoming a ducktrap advocate ;)
<snusnu>
absolutely
<snusnu>
it solves so many common problems
<mbj>
snusnu: nice
<mbj>
snusnu: there is still lots of room for improvement.
<snusnu>
i'm thinking we can use rom-mapper to prototype the mapping dsl, and use ducktrap under the hood
<mbj>
snusnu: You'll dig it ;)
<snusnu>
i already do ;)
<mbj>
snusnu: Especially as ducktrap transformators are compisable.
<mbj>
*composable
<mbj>
It will allow you to combine mappings quite easily.
<mbj>
Maybe you need special nodes for loading-from dumping-to Axiom::Tuple
<snusnu>
dkubb: btw, i was reading through the Dee docs yesterday, especially the parts about their API for constraints and database/cluster was very interesting
<mbj>
You can do custom onces for now.
<snusnu>
mbj: yeah
<mbj>
dkubb: Pls ping matt about my "lets visit in paris" - email.
<snusnu>
dkubb: i'm thinking you kinda envisioned the axiom api for constraints somewhat similar to the one proposed in Dee?
<mbj>
dkubb: stop
<mbj>
dkubb: I'll send a followup first.
<snusnu>
dkubb: i.e., allowing to inject a Constraints object into the relation constructor
<dkubb>
snusnu: I dunno yet. I mean, many kinds of constraints are basically other relational operations that are supposed to return no results
<dkubb>
snusnu: for some common operations, we probably want shortcuts to define the constraints
<snusnu>
dkubb: yeah, or, true/false ? i mean, i think i kinda understood the idea, where they basically model constraints as a function that returns true or false, the inputs being either a tuple for "row-constraints", and the complete relation for "table-constraints"?
<mbj>
dkubb, snusnu: Have to run home and rest a bit. We successfully deployed to production this day.
<snusnu>
dkubb: FK constraints obviously span 2 relations
<snusnu>
mbj: congratz!
<mbj>
thx
mbj has quit [Quit: Lost terminal]
<dkubb>
snusnu: yeah, they typically talk about relation constraints and database constraints, but I think both can be modelled using the same approach.. it's just that when we actually implement them at the datastore layer we'll probably treat them differently
<snusnu>
dkubb: so my thoughts were, we could start modelling the constraint object based on such functions, i.e. let them expose #call primarily, and have different kind of constraint objects that provide "data for #call to operate on"
<snusnu>
dkubb: right, they need to be serializable to DDL
<dkubb>
snusnu: many relation constraints can be used to make CHECK constraints, and ideally column specific constraints
<dkubb>
for example instead of VARCHAR(255) CHECK LENGTH(col) < 50 we CHAR(50)
<dkubb>
whoops
<dkubb>
we'd prefer CHAR(50)
<dkubb>
obviously it's whatever the database allows us to push down
<snusnu>
right, that's some form of "backend specific optimization" .. right
<snusnu>
the key thing is that our constraint objects carry all the information for being serialized to DDL
<dkubb>
right, and I think a normal relation could carry everything