[appengine-java] Re: Mvenizing GAE/GWT project

[har_shan]

See
http://googlewebtoolkit.blogspot.com/2010/08/how-to-use-google-plugin-for-eclipse.html

Specifically, you might want to see the sample maven + gwt + gae
project that they have given :
http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/pom.xml

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Entity relationship designing - best practice

[har_shan]

i want to hear the best practice on establishing entity relationships in my 
case-

Example, for sake of discussion:-
User 
Exam
Page
Question
Answer

As you can see, from top, each entity has 1 - many relationship with entity 
immediately beneath it. 
Interesting case is a User can have any number of Exam and it can *scale* in 
whatever manner, but a Exam usually will have few Pages, 
a Page with few Questions, Questions with few Answers

I saw this interesting post
best practice to persist medium-large 
data
 

(which is also a answer to this ques) and it made me to design like this: 
Also i plan to keep each entity in its own entity group, as recommended by 
AppEngine - totally eliminating Parent relationship, as far as possible

class User{
String name;
// List exams;  NOT a good idea, as this will unnecessarily load 
bulk amt of Exam keys when i load User
...
}

So i would use a query to get all Exams created by any User. Fine. But 

class Exam{
String subject;
// With this i can *quickly* retrieve all Pages with keys, but as Exam and 
Page are not in same Entity Group, 
// how do i maintain *consistency* when, say, i delete a Page and 
accordingly remove that Key entry in Exam.
// Also as said earlier, no. of pages (hence keys) shouldn't be too high, so 
dont need to worry abt size
List pages;  
}

class Page{
String pageNo. 
Key exam; // with this i can *only(?)* use query to get all Pages 
under a Exam, so *unnecessary index scan*[1]
List questions;
}

The same extends to Page -> Question -> Answer

[1] Retrieving via Keys are faster than 
querying
 


So what is your recommendation and why? 
I can suspect that it should be a trade-off between unnecessary loading of 
keys/extra scan of indices but want to get some thoughts and what about 
consistency?

Thanks much in advance.
p.s. though not relevant, most likely i will use low level framework, mainly 
Objectify.. 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Entity relationship designing - best practice

[har_shan]

Yes, understood. Thanks. Am just trying my best to keep entities in
isolation unless am really forced to group them.
There is this use case in my example:
User while creating a Exam, will create, edit, delete any Page,
Question, Answer as they wish.
At regular intervals, say 1 min, i will persist all changes. At this
time, i can be successful in persisting a Page but unsuccessful in
some Question/Answer (say)
So i will just retry failed ones at next save.
I just don't want to put all Page, Question, Answer is same entity
group and fail the save altogether if a particular entity save is
failed - just to maintain integrity of each save.
Makes sense - atleast for my example?

Also what about my relationship mentioned in my prev post?

Thanks again.

On Dec 18, 11:53 am, Didier Durand  wrote:
> Hi,
>
> The most important thing to remember to design your objects and their
> relationship is the entity group: you cannot touch (update, delete,
> create) entities belonging to more than 1 group in a single
> transaction (unless you then use transaction-bound tasks)
>
> So, keep this point in min when you maximize the number of entity
> groups by keeping entities in separate groups: it will make your
> transactional code a little bit harder to develop if you want to
> maintain database integrity.
>
> regards
>
> didier
>
> On Dec 17, 7:43 pm, har_shan  wrote:
>
>
>
>
>
>
>
> > i want to hear the best practice on establishing entity relationships in my
> > case-
>
> > Example, for sake of discussion:-
> > User
> > Exam
> > Page
> > Question
> > Answer
>
> > As you can see, from top, each entity has 1 - many relationship with entity
> > immediately beneath it.
> > Interesting case is a User can have any number of Exam and it can *scale* in
> > whatever manner, but a Exam usually will have few Pages,
> > a Page with few Questions, Questions with few Answers
>
> > I saw this interesting post
> > best practice to persist medium-large 
> > data<http://www.mail-archive.com/google-appengine-java@googlegroups.com/ms...>
>
> > (which is also a answer to this ques) and it made me to design like this:
> > Also i plan to keep each entity in its own entity group, as recommended by
> > AppEngine - totally eliminating Parent relationship, as far as possible
>
> > class User{
> > String name;
> > // List exams;  NOT a good idea, as this will unnecessarily load
> > bulk amt of Exam keys when i load User
> > ...
>
> > }
>
> > So i would use a query to get all Exams created by any User. Fine. But
>
> > class Exam{
> > String subject;
> > // With this i can *quickly* retrieve all Pages with keys, but as Exam and
> > Page are not in same Entity Group,
> > // how do i maintain *consistency* when, say, i delete a Page and
> > accordingly remove that Key entry in Exam.
> > // Also as said earlier, no. of pages (hence keys) shouldn't be too high, so
> > dont need to worry abt size
> > List pages;  
>
> > }
>
> > class Page{
> > String pageNo.
> > Key exam; // with this i can *only(?)* use query to get all Pages
> > under a Exam, so *unnecessary index scan*[1]
> > List questions;
>
> > }
>
> > The same extends to Page -> Question -> Answer
>
> > [1] Retrieving via Keys are faster than 
> > querying<http://www.mail-archive.com/google-appengine@googlegroups.com/msg3384...>
>
> > So what is your recommendation and why?
> > I can suspect that it should be a trade-off between unnecessary loading of
> > keys/extra scan of indices but want to get some thoughts and what about
> > consistency?
>
> > Thanks much in advance.
> > p.s. though not relevant, most likely i will use low level framework, mainly
> > Objectify..

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Entity relationship designing - best practice

[har_shan]

Ah, i missed an important piece.
You are right, Didier. Making all entities to be isolated doesn't seem
to work out, atleast because of this important use case, in my
example:

All Pages will be in particular *order* under any Exam and similarly,
all Questions will be in some *order* as well under any Page, same for
Answers under Question.

So i might do this with a "pageNo" field and to maintain consistency
while updating this field, all Pages should be in entity group of
Exam, all Questions should be same group of corresponding Page - so
that i can update all in a single transaction!

This means, Exam, Page, Question and Answer should all be in same
entity group?!

Should be ok, as this entity group will not be too big - atleast its a
< a User data, as per entity group thumb rule?
Or am missing something.

Thanks,

On Dec 18, 1:22 pm, har_shan  wrote:
> Yes, understood. Thanks. Am just trying my best to keep entities in
> isolation unless am really forced to group them.
> There is this use case in my example:
> User while creating a Exam, will create, edit, delete any Page,
> Question, Answer as they wish.
> At regular intervals, say 1 min, i will persist all changes. At this
> time, i can be successful in persisting a Page but unsuccessful in
> some Question/Answer (say)
> So i will just retry failed ones at next save.
> I just don't want to put all Page, Question, Answer is same entity
> group and fail the save altogether if a particular entity save is
> failed - just to maintain integrity of each save.
> Makes sense - atleast for my example?
>
> Also what about my relationship mentioned in my prev post?
>
> Thanks again.
>
> On Dec 18, 11:53 am, Didier Durand  wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > The most important thing to remember to design your objects and their
> > relationship is the entity group: you cannot touch (update, delete,
> > create) entities belonging to more than 1 group in a single
> > transaction (unless you then use transaction-bound tasks)
>
> > So, keep this point in min when you maximize the number of entity
> > groups by keeping entities in separate groups: it will make your
> > transactional code a little bit harder to develop if you want to
> > maintain database integrity.
>
> > regards
>
> > didier
>
> > On Dec 17, 7:43 pm, har_shan  wrote:
>
> > > i want to hear the best practice on establishing entity relationships in 
> > > my
> > > case-
>
> > > Example, for sake of discussion:-
> > > User
> > > Exam
> > > Page
> > > Question
> > > Answer
>
> > > As you can see, from top, each entity has 1 - many relationship with 
> > > entity
> > > immediately beneath it.
> > > Interesting case is a User can have any number of Exam and it can *scale* 
> > > in
> > > whatever manner, but a Exam usually will have few Pages,
> > > a Page with few Questions, Questions with few Answers
>
> > > I saw this interesting post
> > > best practice to persist medium-large 
> > > data<http://www.mail-archive.com/google-appengine-java@googlegroups.com/ms...>
>
> > > (which is also a answer to this ques) and it made me to design like this:
> > > Also i plan to keep each entity in its own entity group, as recommended by
> > > AppEngine - totally eliminating Parent relationship, as far as possible
>
> > > class User{
> > > String name;
> > > // List exams;  NOT a good idea, as this will unnecessarily load
> > > bulk amt of Exam keys when i load User
> > > ...
>
> > > }
>
> > > So i would use a query to get all Exams created by any User. Fine. But
>
> > > class Exam{
> > > String subject;
> > > // With this i can *quickly* retrieve all Pages with keys, but as Exam and
> > > Page are not in same Entity Group,
> > > // how do i maintain *consistency* when, say, i delete a Page and
> > > accordingly remove that Key entry in Exam.
> > > // Also as said earlier, no. of pages (hence keys) shouldn't be too high, 
> > > so
> > > dont need to worry abt size
> > > List pages;  
>
> > > }
>
> > > class Page{
> > > String pageNo.
> > > Key exam; // with this i can *only(?)* use query to get all Pages
> > > under a Exam, so *unnecessary index scan*[1]
> > > List questions;
>
> > > }
>
> > > The same extends to Page -> Question -> Answer
>
> > > [1] Retrieving via Keys are faster than 
> > > querying<http://www.mail-archive.com/google-appe

[appengine-java] Re: Entity relationship designing - best practice

[har_shan]

Sorry again, another use case:
a Question can be moved to any Page while creating any Exam - so if
have Parent-Child relation between Page-Question,
i might need to delete Question and recreate it with new Parent - BAD
IDEA as told by Jeff in post that i mentioned.

i gave up!

On Dec 18, 1:22 pm, har_shan  wrote:
> Yes, understood. Thanks. Am just trying my best to keep entities in
> isolation unless am really forced to group them.
> There is this use case in my example:
> User while creating a Exam, will create, edit, delete any Page,
> Question, Answer as they wish.
> At regular intervals, say 1 min, i will persist all changes. At this
> time, i can be successful in persisting a Page but unsuccessful in
> some Question/Answer (say)
> So i will just retry failed ones at next save.
> I just don't want to put all Page, Question, Answer is same entity
> group and fail the save altogether if a particular entity save is
> failed - just to maintain integrity of each save.
> Makes sense - atleast for my example?
>
> Also what about my relationship mentioned in my prev post?
>
> Thanks again.
>
> On Dec 18, 11:53 am, Didier Durand  wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > The most important thing to remember to design your objects and their
> > relationship is the entity group: you cannot touch (update, delete,
> > create) entities belonging to more than 1 group in a single
> > transaction (unless you then use transaction-bound tasks)
>
> > So, keep this point in min when you maximize the number of entity
> > groups by keeping entities in separate groups: it will make your
> > transactional code a little bit harder to develop if you want to
> > maintain database integrity.
>
> > regards
>
> > didier
>
> > On Dec 17, 7:43 pm, har_shan  wrote:
>
> > > i want to hear the best practice on establishing entity relationships in 
> > > my
> > > case-
>
> > > Example, for sake of discussion:-
> > > User
> > > Exam
> > > Page
> > > Question
> > > Answer
>
> > > As you can see, from top, each entity has 1 - many relationship with 
> > > entity
> > > immediately beneath it.
> > > Interesting case is a User can have any number of Exam and it can *scale* 
> > > in
> > > whatever manner, but a Exam usually will have few Pages,
> > > a Page with few Questions, Questions with few Answers
>
> > > I saw this interesting post
> > > best practice to persist medium-large 
> > > data<http://www.mail-archive.com/google-appengine-java@googlegroups.com/ms...>
>
> > > (which is also a answer to this ques) and it made me to design like this:
> > > Also i plan to keep each entity in its own entity group, as recommended by
> > > AppEngine - totally eliminating Parent relationship, as far as possible
>
> > > class User{
> > > String name;
> > > // List exams;  NOT a good idea, as this will unnecessarily load
> > > bulk amt of Exam keys when i load User
> > > ...
>
> > > }
>
> > > So i would use a query to get all Exams created by any User. Fine. But
>
> > > class Exam{
> > > String subject;
> > > // With this i can *quickly* retrieve all Pages with keys, but as Exam and
> > > Page are not in same Entity Group,
> > > // how do i maintain *consistency* when, say, i delete a Page and
> > > accordingly remove that Key entry in Exam.
> > > // Also as said earlier, no. of pages (hence keys) shouldn't be too high, 
> > > so
> > > dont need to worry abt size
> > > List pages;  
>
> > > }
>
> > > class Page{
> > > String pageNo.
> > > Key exam; // with this i can *only(?)* use query to get all Pages
> > > under a Exam, so *unnecessary index scan*[1]
> > > List questions;
>
> > > }
>
> > > The same extends to Page -> Question -> Answer
>
> > > [1] Retrieving via Keys are faster than 
> > > querying<http://www.mail-archive.com/google-appengine@googlegroups.com/msg3384...>
>
> > > So what is your recommendation and why?
> > > I can suspect that it should be a trade-off between unnecessary loading of
> > > keys/extra scan of indices but want to get some thoughts and what about
> > > consistency?
>
> > > Thanks much in advance.
> > > p.s. though not relevant, most likely i will use low level framework, 
> > > mainly
> > > Objectify..

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Entity relationship designing - best practice

[har_shan]

Thanks all for comments. It really helped.

I settled in this relationship which seems solve all problems, atleast
as of now.

Entity Group (EG) #1
User -  User related CRUD can be done

EG#2
Exam  -Exam related CRUD can be done

EG#3
PageIndex   - Contains all (keys of) Pages under
Exam, in order. Page CR and D, (re)ordering of Pages can be done
simply & maintaining data integrity.
Page   - Page CRUD can be done. Deletion
will just happen in PageIndex first and then here. Can also done in
transaction if needed as we are in same EG
QuestionIndex  - Contains all (keys of) Questions
under a Page in order. Question (re)ordering can be done. Note
Question can be reordered within a Page or from 1 page to another and
can be done as all QuestionIndex  are in same EG. Also Question CR, D
can be done.

EG#4
Question-  Actual Question CRUD. Like Page,
deletion of Question will happen in QuestionIndex (yes only its key)
and lated propagated to actual entity here. Its ok if deletion of key
of Question happens in QuestionIndex passes and it fails when actual
Question is deleted, as we can try again later and the single source
of truth would be QuestionIndex
Answer   - Answer CRUD

Hope this also helps someone.
I would be happy if someone points out flaws in my modeling.

Andy,
Am not clear about yr question. May be if you could show what are the
relevant entities and what exactly should be the relationship btw
them, i can share my 2 cents.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.