Hi,
I have some worries concerning entity design in the G. Datastore.
The non-relational organization of the Data Store kinds of complicates it,
a little, to plan an efficient Entity design to organize your data.
In Particular, the Data Store seems to be governed by the concept that
every entity-relationship implies that one of the entities is a parent of
another.
Of A and B are related, either A or B is a parent of the other.
In short, the concept of composition if thrown complely down the can. All
we have is a pseudo Super/Subclassing hierarchy that is implied between all
entities.
The concept that B may exist by itself, and that A does not own B but
instead simply knows of B does not seem to be there.
In the end, for now, this truns into the following difficulty.
Say that we have a data model comprised by the following two concepts:
(a) Types of Day, recursively related to itself in a hierarchical structure.
Tree illustration E.g :
--- Sunny
------ Hellish Suny
------ Cloudy Sunny
-- Rainy
------ Deluge
------ Heavy Rain (like the PS3 game)
----- Typical UK Day
-- Stormy
-- Snowy
and so on.
In terms of pseudo code, this entiy Would be Something like
@PersistenceCapable
class DayType{
@PrimaryKey
@Persistable
Key key; // key of app engine
@Persistable
String name;
@Persistable
DayTpe parent;
@Persistable(annotation maps to parent)
HashSet<DayType> children;
}
(b) Then I would have some ocurrence record, which would record what type
of day was registered (every day).
class DayRecord{
KeyOfAppenGine key;
Date ocurrenceDt;
DayType type;
}
Now, if i did something like this, I would not be able to persist my
DayRecord enties. I would go as far as populating the DB with my DayType
categories, but no further.
If I tried to do more, what I would see would be an exception saying that I
could not register my DayRecord because this new entity would be trying to
stamp itself as the parent of the DayType entity.
For instance, it might tell me that UK Typical Day already had been
stamped with a parent relationship to Rainy Day and my trying to set it to
the current DayRecord was an error. (In a relational model, however, this
would have been solved with a simple forigen key on the DayRecord entity).
Anyway, when, in cases like this, where you have some generic classes like
DayType to categorize you records it seems that you have no alternative but
to imbue into your category class a property to make it a parent of your
ocurrence records.
In this case, for example, I would have to enrich my DayType class with a
new field say:
HashSet<DayRecord> ocurrences;
This looks pretty scary to me, because if I ever need to load a DayType
entity, I definatly do not to be bringing along with it almost the whole
database simply because it has a map of DayRecords. Ever dayRecord for UK
Typical Days would be comming a long, and we all know that it rains a lot
over there.
So, what is the best strategy here?
Is there a better way to model this.
E.g. Ist it actually possible to have the DayType property set on the
DayRecord without having appEnging trying to make a paret of DayType?
Or do I simply need to make sure that I never load DayType entities, and
that instead I shall run simple queries where I specifically identify the
few properties of the DayType entity that I wish to see loaded?
Thank you for your help,
My kindest regards.
--
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/-/CJZdGXU0lk0J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
