As far as I know there are two possible solutions:
*Review the architecture inserting Elements as a list property of your
domain, something like
@PersistenceCapable
class Domain{
private ArrayList<Element> elements;
}
This works correctly and you get the benefit to have a cascasing
delete on elements when you delete the Domain they're part of.
This does not seem to have significant drawbacks, as documentation
says somewhere Elements are fetched from datastore only if you access
the list, and not if you just read the Domain without actually going
thru the list.
Elements are also queriable without reading the actual Domain they're
in.
The only thing this architecture seems to impede is finding the domain
an element belongs to, given the element, without having complex
iterations.
* Check if domain exists outside the transaction.
If your domains are not deleted during an Element insert this should
work.
I've gone the first path for my application and benefits in terms of
code complexity and maintenance have been worth the effort, anyway it
depends on your business logic if that can be right.
Regards
Lorenzo
On Jul 24, 4:04 pm, Bill <[email protected]> wrote:
> Hello,
>
> I'm quite frustrated with entity groups. They seem to make the
> concept of a transaction largely pointless.
>
> The specific problem I face at this moment is this. Since the
> datastore has no concept of foreign key constraints, I need to do
> bounds checking. Here's the case:
>
> There exists a Domain type, and an Element type. An Element requires
> a reference to a pre-existing Domain in order to function, per my
> business rules. Domains exist independently of Elements, and are
> administered separately. I would characterize their relationship as
> "Element has a reference to a required Domain's primary key" rather
> than "Element is a child of Domain".
>
> When creating an Element, I need to check that the reference to the
> assigned Domain is not bogus. I do this in my service layer, which is
> also where I want to determine transactionality.
>
> The algorithm goes like this:
>
> * start transaction. Per my current architecture I cannot start this
> transaction any later without creating an entirely new non-
> transactional business delegate layer that feels like absolute
> overkill.
> * retrieve Domain by key. If no such Domain is found, throw an error
> * insert Element
> * commit
>
> Unfortunately, this causes the dreaded "can't operate on multiple
> entity groups in a single transaction" exception. I'm absolutely
> hornswaggled by this, since I'm not "operating" on the Domain. I just
> want to check that it exists! If this were a destructive change I
> were making, I'd kind of -- barely -- see the argument here, but why
> on earth is this a problem? Am I missing something?
--
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 [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-java?hl=en.
