Comment 14 for bug 788590

The reason owned relationships didn't work was it kept throwing an
error along the lines of "entity relations can't have more than one
ancestor". I did initially refactor it to what I thought was a tree
like structure - each entity had only one parent (but multiple
children) but it still complained so I made everything unowned. It
seemed like there could only be one owned parent and one owned child
for each entity from memory of further reading I did at the time

On 31/05/2011, at 10:59 AM, Matt Giuca <email address hidden>
wrote:

>> Just to clarify entity groups;
>> In an owned relationship both objects are in the same entity
>> group. Thats
>> why you can only have very simple entity relations as owned
>> relationships.
>
> OK that makes sense. I'm used to the Python datastore API (which I've
> used in more detail). It's lower level than JDO and doesn't have a
> concept of "owned relationships", but objects can have "parents",
> which places an object, its parents, and its siblings, in the same
> entity group, and that lets you do transactions.
>
> Do you remember the exact reason why owned relationships didn't work
> out for us? We possibly should have stuck with them. But I suspect it
> will be too hard to refactor now.
>
>> But in that regard, why isnt this transactional nature defualt?
>> Surely you
>> would *always* want lookups to the datastore to be in transactions to
>> prevent
>> the cases we're having to code around here. Thats what i dont
>> understand
>> about the way GAE works.
>
> Well transactions can't be the "default" in any database system
> because you haven't specified what operations need to be done
> together. Transactions have a high overhead, and you wouldn't want
> them on all the time. For example, consider a request in an email
> program that sets the "mark as read" flag to "true" for every row of a
> table that matches a certain query, and it includes 1000 rows. There's
> no need for that to be done atomically. If it marks 500 emails as
> "read" and someone simultaneously queries the state of the inbox, it
> won't matter if you show half the emails as read and half as unread,
> then a few seconds later you finish showing them all as read. That
> doesn't need to be in a transaction. But if you did put it in a
> transaction, you would be blocking all mail operations until the 1000
> emails are all marked as read.
>
> Besides, it couldn't automatically apply a blanket rule such as
> "handle all HTTP requests in a full transaction", because of the
> conditions above -- it would restrict your HTTP request to only deal
> with a single entity group (which for our program at the moment would
> mean a single entity).
>
> --
> You received this bug notification because you are subscribed to
> MUGLE.
> https://bugs.launchpad.net/bugs/788590
>
> Title:
> Lots of UserGameProfiles created simultaneously
>
> Status in Mars Programming Language:
> Invalid
> Status in Melbourne University Game-based Learning Environment:
> Triaged
>
> Bug description:
> For every "real" user game profile created, there are about 10
> completely blank ones, without even a user.