<endformationage>
I read through this awhile ago, and from what I can remember, there may be some compatible ideas with its concurrent features that Pony's capabilities may be a good fit.
<endformationage>
I think a Pony wrapper would be useful, FWIW. Perhaps with some niceties.
k0nsl has quit [Quit: “If we don't believe in freedom of expression for people we despise, we don't believe in it at all — Noam Chomsky”]
k0nsl has joined #ponylang
k0nsl has quit [Changing host]
k0nsl has joined #ponylang
<obadz>
endformationage: looks like the double-buffer approach de MVCC here should mean that only a single thread can write
<obadz>
(though all the others can read on the "other" buffer)
<obadz>
not that that's the end of the world..
<mindB>
Hello everyone, I'm considering writing a project in (and learning) Pony. The thing holding me back is that nobody seems to have written an ORM or other way of interfacing with SQL. Is there a package out there that I'm missing?
<obadz>
mindB: seems like the trivial nature with which one invokes C from Pony should make this easy?
k0nsl has quit [Quit: “If we don't believe in freedom of expression for people we despise, we don't believe in it at all — Noam Chomsky”]
fluttershy_ has joined #ponylang
k0nsl has joined #ponylang
k0nsl has joined #ponylang
k0nsl has quit [Changing host]
<fluttershy_>
SeanTAllen: yes many ColProductCalculators
<fluttershy_>
same number as the number of columns
<fluttershy_>
SeanTAllen: so for every column I was thinking to create an actor, see here https://ibb.co/kUZH7a
<fluttershy_>
should have been doing it also for the sum next (for every line ) but for now just going with the product and see if that's gonna scale.
<SeanTAllen>
so you would want to do the iso trick from TCPConnection that we discussed
<fluttershy_>
yes
<fluttershy_>
because I pass the 2d array to the master actor (ProductDist) as iso and inside will do in place transpose, I don't want to create memory overhead. and then transpose back and return the matrix reference.
<fluttershy_>
2d array i mean matrix
<endformationage>
obadz: True, a single writer. I'm not sure how or when multiple writers for a kv store would even work. If i've learned anything from Pony's teachings of the issues, it would cause the problems Pony strives to avoid.
<endformationage>
SeanTAllen: I am curious as to what cross key access means?
<SeanTAllen>
so normally in a key value store you only have access to single key at a time in terms or read or write
<SeanTAllen>
in that case
<SeanTAllen>
the way to implement in Pony (naively) would be an actor per key
<SeanTAllen>
this works unless you are trying to do something fancy like "i want to update these two key atomically" which gets really tricky.
<endformationage>
I guess I see that latter as being the more common (I'm seeing it from a graph database perspective). But again I'm not terribly versed.
<SeanTAllen>
what is "the latter"?
fluttershy_ has quit [Quit: Page closed]
<endformationage>
An atomic update of multiple keys
flutter57 has quit [Ping timeout: 240 seconds]
<SeanTAllen>
i dont think a k/v store is a good tool if that is your use case
jemc has joined #ponylang
<endformationage>
Well, I used a framework that mapped onto a KV Store (LMDB)
<endformationage>
So it wasn't direct manipulation
<obadz>
SeanTAllen: how do you index all the actors?
flutter63 has joined #ponylang
<endformationage>
Actually, there are a number of graph DBs which use LMDB according to their site.
fluttershy_ has joined #ponylang
fluttershy_ has quit [Client Quit]
<SeanTAllen>
obadz: well, thats an interesting question
<SeanTAllen>
obadz: are your keys all strings?
<obadz>
let's assume that's the case
<SeanTAllen>
i think that depends on your constraints. your simplest would be to have an index actor that you send the key to and get back a tag of the actor for that key which you can then direct your request to
<SeanTAllen>
performance there isn't going to be great as that index actor becomes a bottleneck
<SeanTAllen>
could could divide that index of keys up across a number of index actors
<SeanTAllen>
this is better for performance
<SeanTAllen>
you also need to work out coordination of the creation of new keys and their actor and how that gets stored
<SeanTAllen>
i assume you want to be guaranteed to read a key immediately after its created so there's some coordination there
<SeanTAllen>
if you want to scale across machines, you'd need to store something other than a tag that would allow you to route to other machines to do queries and updates.
<obadz>
yeah this sounds quite tricky & manual (even on a single host)
<SeanTAllen>
its quite easy to do if your constraints allow
<SeanTAllen>
but you'll end up with the same issue even outside of pony
<SeanTAllen>
how do you maintain an index that isnt a bottleneck and where you can access all your keys concurrently? its not an easy problem once you make performance a concern. but it can certainly be done.
<SeanTAllen>
obadz: so, what sort of constraints are you putting on yourself?
nyarum has quit [Remote host closed the connection]
nyarum has joined #ponylang
bimawa has quit [Read error: Connection reset by peer]
nyarum has quit [Remote host closed the connection]
nyarum has joined #ponylang
nyarum has quit [Remote host closed the connection]
nyarum has joined #ponylang
nyarum has quit [Remote host closed the connection]
nyarum has joined #ponylang
nyarum has quit [Remote host closed the connection]
flutter63 has quit [Ping timeout: 255 seconds]
flutter83 has joined #ponylang
nyarum has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]