Yep, that defaultFetchGroup worked nicely! I sent you an email, let
me know if it did not arrive.
On Nov 9, 2:38 pm, bryce cottam wrote:
> hey James,
> I usually do a defaultFetchGroup="true" on my embedded classes ('cause
> I always want them), but this makes it so that the embedded class is
>
hey James,
I usually do a defaultFetchGroup="true" on my embedded classes ('cause
I always want them), but this makes it so that the embedded class is
always loaded. This generally isn't a problem because embedded values
are contained in your entities record in the data store. However,
there is
Bryce, I tried another use of your "embedded class" related to Audit
fields on an Entity. For consistency in approach to Auditing entity
data, typically you would add the following 4 fields to each entity in
your design: createBy, createdDate, updatedBy, and updatedDate. I
thought I'd place thes
here's a really good talk about how objects are mapped into the
BigTable datastore and how relationships are actually represented in
the system:
http://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore
this sort of highlites how relationships actually work in BigTable
(w
Good points. In my case, so far, the copied objects are small and not
complicated, which is why my method appealed to me.
I feel like there's some fundamental concept that I'm not getting and it has to
do with how objects are mapped onto the Big Table data store. Watching the
videos from Goo
I don't think that duplicating the whole Department object as a child
of a Person is all that good of an idea. First off, if the Department
object gets complicated and has it's own child objects all that data
will be living on the Person, which isn't really needed. The whole
reason for the FK st
I'm now thinking that instead of using detachable="false", set it to true so
that it can be easily updated. To create new unparented objects, use a
constructor that takes a "template" object you got from the data store;
Department fetchedDepartment = departmentDao.findById(id);
Department
Thinking out loud here:
When you use that encoded string format you can use it wherever you'd use Key.
The apparent advantage of using the encoded string format is that your dto
isn't exposing GAE's Key. With the encoded string your service layer can be
oblivious about GAE's Key, without any
Rusty, Thanks for the code sample! How do you decide when to use key
type of "Key" vs "String"?
On Nov 4, 1:45 pm, James H wrote:
> Datanucleus, both suggestions worked but I like the "embeddedOnly"
> best in order to avoid a dummy key on every FK class!
>
> Bryce, I no longer get the error abo
Datanucleus, both suggestions worked but I like the "embeddedOnly"
best in order to avoid a dummy key on every FK class!
Bryce, I no longer get the error above...I just added
embeddedOnly="true" to the PersistanceCapable tag in BookFk class.
You're right, I could use the collection technique on t
> Needs a PK either way. Pick a field, any field.
Or just set "embeddedOnly" as true ... if you really never want to
persist one of those in its own right
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App E
> BookFk is an embedded class intended to be used by entities like
> Chapter and others.
Needs a PK either way. Pick a field, any field.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" gr
BookFk is an embedded class intended to be used by entities like
Chapter and others. It is NOT intended to be a standalone entity or
have a Primary Key. So, when I try your fix I get the following
compile error:
SEVERE: Class struts2.example4.BookFk has application-identity and no
objectid-clas
Why is BookFK trying to use Datastore Identity ? (as the message says)
"identityType=IdentityType.APPLICATION" would be recommended
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
Rusty, where did you get that quote? It sounds familiar... Hell
yeah, GAE is all about wrestling with persistence since it is
Hierarchial instead of Relational and the distributed transactional
nature. That changes an app tremendously. Among my concerns are
being able to move an app out of GAE
Hi James,
sorry for the delay,
My design is currently similar to what you proposed. However, in your
example, I'd probably make 2 classes: PersonFK and InstitutionFK.:
public class PersonFK {
private Key id;
private String firstName;
private String lastName;
private String ci
"Persistence is supposed to be simple but I sense alot of struggling going on
here with GAE."
+1
--~--~-~--~~~---~--~~
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
I don't know if this will help, but I finally figured out how to do parent
queries using the parent's primary key. At the moment I don't see what
advantage there is if you're storing a reference to the parent object in the
child and using mappedBy in the parent, but here's what I have, in case
Consider this test case. A Person belongs to 1 or more Institutions
so there's 2 ways you would want to query this. Query #1: Given a
particular Person then which Institutions does he belong to? Query
#2: Given a particular Institution then which Persons are members?
Assume entity Person and
Ok Bryce...I'm back. Going to test with your ideas now. In my case,
I tend to avoid generic column names like "id" in favor of "bookId"
and "chapterId" so I should not have any naming conflicts (at least
rarely). Also, my FK embedded classes should not have any collections
though I have a feeli
Sounds good James.
The owned relationship between Book and Chapter is just defined by the fact
that Book has a collection of Chapter as a member variable. If the
relationship is bi-directional (i.e. Chapter has a Book as a member
variable) then you use the mappedBy field in the @Persistent annotat
Hi James. JDO allows this, yes, but App Engine's datastore does not support
joins. Hence, even though the standard technically supports this type of
query, you will not be able to execute it in App Engine.
For one-to-one relationships, you can use an embedded object to achieve this
kind of query:
Right, denormalization is promoted by the Max Ross video as in your
2nd case so from a software design perspective can the "copy fields"
in Employee be contained in their own class and referenced from
Employee in a fashion that allows JDO to still work such as:
class CompanyFK {
// copy of prop
I'm not sure if your taking of the problem is correct. To my mind it
runs:
You have Company and Employee. Company has many Employees and Employee
is working for one company. "Normalized" version looks like:
class Company {
@Persistent private String companyName;
@Persistent private String
24 matches
Mail list logo
