Modelling Many to Many Relationship - Is the GAE Documentation's example appropriate for my model?

[King]

Hi all :)

Let's say I have a app called "Opposites Attract".  And in it I have a User model, and each user has a list of Likes and a list of Dislikes.

Each USER can have a maximum of:
- 200 Likes.
- 200 Dislikes.

I want to query this information to find out for a given Like, what other users Dislike it or vice versa.  I don't need to return EVERY person that likes or dislikes a particular thing.  If I just returned the first 100 people found to like/dislike a particular thing, that would be acceptable.  How would it be best to model this?

Here (http://code.google.com/appengine/articles/modeling.html) it speaks of a potentially similar example under the Many to Many example, and if I were to implement it in this way, I would have a class like so:

class User(db.Model):
    likes = db.ListProperty(db.Key)
    dislikes = db.ListProperty(db.Key)

where the keys in both lists would refer to items from a Thing model.

What I'm wondering is in the App Engine Documentation's example they mention:
"In the example above, the Contact side was chosen because a single person is not likely to belong to too many groups, whereas in a large contacts database, a group might contain hundreds of members."

With that quote in mind, does this method suit my example?  I want to design this app so that hundreds of thousands of people can like or dislike a thing. So I would feel better if the above quote read "whereas in a large contacts database, a group might contain hundreds (OF THOUSANDS) of members."

Also though I expect this doesn't change how I model this particular relationship I feel I should mention this in case it does:
While my concern at the moment is searching ALL users that like or dislike a particular thing, my next step would be to search by Gender and Location 
For example:
"all GIRLS who likes Dogs"
"everyone in Los Angeles who dislikes Cats"

[David Mora]

Depending on your entity group/transaction strategy here you might want to consider Referencing Users to a Dislike/Like Kind:

http://code.google.com/appengine/docs/python/datastore/datamodeling.html#References

What happens is (and premature i can say so) your like, dislikes properties are going to generate a lot of zig-zagging (due to merge join) when you query for this information (also depending on your index strategy)

class User(db.Model):

 .....

class Like(db.Model):

    topic = db.StringProperty() #enumeration

    user = db.ReferenceProperty(User)

class Dislike(db.Model):

    topic = db.StringProperty() #enumeration

    user = db.ReferenceProperty(User)

Your key strategy can be (serial of topic + user.key().name())

And then you can use a pipeline to go thru your Like, Dislike structures and build a de-normalized Kind you can query safely on.

- i think -

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/m3lX4RQ3FXoJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
http://about.me/david.mora

[King]

Hi David,
I'm having some trouble understanding your reply

class Like(db.Model):

    topic = db.StringProperty() #enumeration

    user = db.ReferenceProperty(User)

 
By enumeration, do you mean a number representing the thing being liked?
So for example
topic = 5
(where 5 might mean "Dogs")?

Your key strategy can be (serial of topic + user.key().name())

Are you saying the key for a Like might be ("Dogs" + "John Smith")?

Forgive me, I might be too much of a newb to understand this.

[David Mora]

Hi King, 

I'm learning this thing here too so don't worry :)

On 9 June 2011 19:54, King <sirh...@gmail.com> wrote:

Hi David,
I'm having some trouble understanding your reply

class Like(db.Model):

    topic = db.StringProperty() #enumeration

    user = db.ReferenceProperty(User)

 
By enumeration, do you mean a number representing the thing being liked?
So for example
topic = 5
(where 5 might mean "Dogs")?

All depends on how you are going to distribute your "topics" or "subjects". My example was just a way to point out the relation, not actually what you should be doing. Some people like to store strings directly, others enumerations, others a parent+child relation. It all goes down to what you feel more confortable with.

 

Your key strategy can be (serial of topic + user.key().name())

Are you saying the key for a Like might be ("Dogs" + "John Smith")?

Correct :) - That gives you _many_ users liking many _subjects_ in one Entity Kind

There are going to be obvious implications on what other queries you might need, but given your initial requirements it seems you need to tend to distribute those models so you don't kill an indexing server with many variations.

 

Forgive me, I might be too much of a newb to understand this.

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/pzkk-e4SqwIJ.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
http://about.me/david.mora