does anyone have bindings that presents google datastore as a "persistent datascript" ?
with google app engine, what is the easiest way to take payment?
@qqq re: datascript, i assume you know datastore does not support joins?
i'm working on a clojure ds query interface. AND is easy: pass a map whose vals are predicate fns. for OR, pass a set of such maps.
join is a whole 'nother matter.
e.g. {:age #(> % 27)} returns all entities with age > 27.
still don't have a good syntax for projection queries, tho. thoughts?
e.g. #{{:age #(> % 27)} {:name "Smith"}} returns all entities with age > 27 OR name = "Smith". whaddya think?
@mobileink : that would expalin it! turns out, I don't think I need joins
@mobileink : so gae charges per read right?
given that's the case, I thikn maybe for loops would be better than a DSL
since I readlly want to know what indezes it's hitting and estimate the cost
hah ha! i'm a cheapskate freeloader! unfortunately (or not) i've never been in a position to worry about costs. my main (and only, so far) concern is readability, clojurishness, simplicity. i'm just assuming i can optimize, later.
well I'm building a startup, so it's either (1) my traffic is so damn low I'm not making money or (2) I have high traffic and I need to be able to estimate READ costs
gae ds indexing is a whole 'nother matter, i admit i've ignored it so far.
if you're not using indezes, yo're linear searching, and that is edpensive
memory hazy, but doesn't gae automagically create at least some indices?
you just need to be careful when you're doing more complex queries. the gae docs give some optimization examples.
the gae costing model is dauntingly complex. you almost need to hire another person just to deal with it.
you kinda get good and bad. good: gae manages everything. bad: you need an mba with a minor in rocket science to figure out your costing model.
no
you just count operations
whatever "costing model" means. i just made that up, cause it sounds kinda sorta professional.
https://cloud.google.com/datastore/pricing is pretty clear
as long as we can estiamte our # of reads
which is what makes indexes so nice as opposed to linear scanning
AWS pricing on the other hand, makes IRS forms look simple
:simple_smile: never looked at aws pricing. gae pricing, ok, they do break it down nicely.
but like i said that's both good and bad
still, i guess it beats trying to cost out what it would take to run your own infrastructure.
re: reads, there's also memcache, which has it's own cost model. if your reads fit the profile, mc is very nice
er, apparently the memcache cost model is no-cost. :simple_smile: