I think we're going to end up implementing using an ARRAY, but I wanted to support many concurrent update requests that can add to this array. Bit.ly is just one example of this use-case in our app. It seems like we'll have to limit concurrency at the update clients, or use locking, to avoid last-write wins removing valid data.
Thanks, Rob On Thu, May 15, 2014 at 11:02 AM, James Taylor <[email protected]>wrote: > Hi Rob, > Would two parallel arrays work (or a single array since it sounds like the > raw and expanded bitly_links are both VARCHARs)? In Phoenix, an array must > be submitted from the client in its entirety, so I don't think you'd need > locking (if you're ok with last-update-wins semantics). > > Thanks, > James > > > On Wednesday, May 14, 2014, Rob Roland <[email protected]> wrote: > >> Hi all, >> >> I have a use-case that would benefit well from a MAP type, similar to how >> Hive uses a map. I'd like to avoid using a JOIN, due to the amount of rows >> on each side of the JOIN. In Hive's case, you would assign a column family >> to the MAP field. >> >> Essentially, I have an entity that I want to add quite a bit of dynamic >> data that would be unknown at both initial query time and query time. A >> contrived example is below: >> >> I'd like to do something like this: >> >> CREATE TABLE facebook_post ( >> id VARCHAR PRIMARY KEY, >> post_body VARCHAR, >> bitly_links MAP<VARCHAR, VARCHAR> >> ); >> >> SELECT * FROM facebook_post; >> >> As opposed to: >> >> CREATE TABLE facebook_post ( >> id VARCHAR PRIMARY KEY, >> post_body VARCHAR >> ); >> >> CREATE TABLE facebook_post_links ( >> facebook_post_id VARCHAR, >> bitly_id VARCHAR, >> expanded_link VARCHAR, >> CONSTRAINT pk PRIMARY KEY (facebook_post_id, bitly_id) >> ); >> >> SELECT * FROM facebook_post AS fp >> LEFT OUTER JOIN facebook_post_links AS fpl ON (fpl.facebook_post_id = >> fp.id); >> >> I realize that a MAP type is outside of the SQL standard, but it would be >> excellent in my use-case. I could accomplish this with an ARRAY type, but >> the expansion of bit.ly links happens as a post-processing step, and >> would probably involve locking, as appending to an ARRAY has to happen >> client-side. >> >> I'd be willing to take a shot at making a MAP type, but I would want to >> make sure this change would be welcomed into mainline Phoenix before >> embarking on something like this. >> >> Thanks, >> >> Rob Roland >> >
