Jonathan Santos Jonathan Santos - 1 month ago 12
Java Question

Objectify POST/LIKE/USER Relationship

I'm modelling a google datastore with objectify and part of my datastore has these 3 elements:

User post new Post which can be liked by many Users

User post a new Post which can be liked by many Users (typical social network).

So far I have User:

@Entity
public class UserMW {

@Id
private Long id;

@Index
private String email;

...
}


Post:

@Entity
public class PostMW{

@Id
private Long id;

@Load
private Ref<UserMW> owner;

...
}


And Like:

@Entity
public class LikeMW {

@Id
private Long id;

@Load
private Ref<UserMW> user;

private Key likedObject;

...
}


It works perfectly and meets all my needs till now. The problem is now I don't know for which way I should go to unlike a post (delete an entity from kind Likes).

I have the User and the likedObject Key to delete it so if it was in a relational database would be very simple (just a delete with a "where" by userID and likedObjectID) but on Objectify...

I could think about 2 ways:

1 - @index on both attributes of Likes entity then query it and delete (but @Index is so expensive and table Likes is gonna be giant!! Doesn't sound as a good idea)

2 - @Parent on user attribute of Likes entity and @Index on likedObject then query by ancestor then filter by likedObject Key and delete (but if I use @Parent, I understood all the time I load 1 user I'll load ALL HIS LIKES and as I said, table Likes is gonna be giant!! Doesn't sound as a good idea either)

Any suggestion to resolve my problem?

Thank you guys!

Answer

I would go with adding another index to the Like entity as that is the simplest working solution, especially considering datastore's newish pricing which also makes it a bit cheaper:

...writing a single entity only costs 1 write regardless of indexes and will now cost $0.18 per 100,000. This means writes are more affordable for people using multiple indexes. You can use as many indexes as your application needs without increases in write costs.

Note that indexes still take storage and likely affect performance but you can be a bit more liberal when using them...