Actually this is what I'm doing…
A as an unique ID, lets call it A-UID
A and B are stored in the bucket with keys A-UID and B-UID
The link in B for A will be named A-UID
And link in A for B will be named B-UID
Thanks,
Morgan.
Le 20 juin 2012 à 15:28, Bryan Fink a écrit :
> On Wed, Jun 20, 20
On Wed, Jun 20, 2012 at 8:00 AM, Morgan Segalis wrote:
> Why would you think that fetch both user and look through the links is
> fastest than A -> B -> A ? Are links really that slow ?
It's not that links are that slow, but that they're not that focused.
Unless you're using B's key as the tag o
Hi Bryan,
Thank you for your answer, that is what I was looking for at first !
Why would you think that fetch both user and look through the links is fastest
than A -> B -> A ? Are links really that slow ?
Thanks,
Morgan.
Le 20 juin 2012 à 13:41, Bryan Fink a écrit :
> On Tue, Jun 19, 2012
Hi Eric,
Thank you for your answer.
Yeah apparently, Links are not the Eldorado I though it was.
In my head it was a pointer to another record, and accessing it would be faster
than regular requests…
I'm not really looking for more than 100 friends in one user's list really.
(Except the rare u
On Tue, Jun 19, 2012 at 12:35 PM, Morgan Segalis wrote:
> Hi everyone !
Hi, Morgan.
> 1 - Are Link walking in Erlang fast & easy ?
Link-walking in the Erlang client is provided via the MapReduce
interface. Instead of a 'map' or 'reduce' phase, specify a 'link'
phase like:
{link, Bucket, Ta
Links may not be the most appropriate way to model a set of associated
users. They have a limited length and both the user data and the
links have to be saved at the same time.
What you can do is emulate a set using a separate bucket and secondary indexes.
So basically the bucket would look like
