impactrudia / objectify-appengine

Automatically exported from code.google.com/p/objectify-appengine
MIT License
0 stars 0 forks source link

transactionless() does not respect namespace #199

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. call this (in my case this is called from a pull queue - that should be 
irrelevant)

NamespaceUtils.swap(taskTag.getNamespace());

logger.info("Namespace: " + NamespaceManager.get());

try {

    ofy.get().transactNew(2, new VoidWork() {
        public void vrun() {
            final Map<String, Collection<?>> taskWorkContext = new HashMap<String, Collection<?>>();

            eventBus.post(new OfyQueueBeforeSaveEvent(tag, entities, taskWorkContext));

            Map<Key<Object>, Object> result;

            NamespaceUtils.swap(taskTag.getNamespace());
            try {
                logger.info("Namespace: " + NamespaceManager.get());
                result = ofy.get().transactionless().save().entities(entities).now();
            } finally {
                NamespaceUtils.restore();
            }

        }
    });

} finally {
    NamespaceUtils.restore();
}

What is the expected output? 

Entity saved into its namespace (that was logged as expected - see code).

What do you see instead?

Entity saved into default namespace.

What version of the product are you using? On what operating system?

5.0.1

Please provide any additional information below.

Original issue reported on code.google.com by jan.g...@gmail.com on 10 May 2014 at 6:53

GoogleCodeExporter commented 9 years ago
Correction: As I tested it without transactionless, it seems to have nothing to 
do with that - the reslult was the same

Original comment by jan.g...@gmail.com on 10 May 2014 at 7:15

GoogleCodeExporter commented 9 years ago
Correction 2: actually called from a push queue! (that is dealing with another 
pull queue inside:)

To deal with the problem, I'm probably supposed to add task to the queue with 
the appropriate namespace set on the maanger. 

This is not objecctify issue/

Original comment by jan.g...@gmail.com on 10 May 2014 at 7:21

GoogleCodeExporter commented 9 years ago
After a final experinment, this is objectify issue after all. I changed code to:

NamespaceUtils.swap(taskTag.getNamespace());
try {
    logger.info("Namespace before: " + NamespaceManager.get());

    DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();

    datastore.put(new Entity("Employee", "asalieri"));

    result = ofy.get().save().entities(entities).now(); // after they fix the bug: ofy().get().transactionless().save()....

    logger.info("Namespace after: " + NamespaceManager.get());
} finally {
    NamespaceUtils.restore();
}

//ofy.get() is just:
@Override
public Objectify get() {
   return ObjectifyService.ofy();
}

and native datastore entity is saved in the correct namespace, while saving via 
objectify will save to a default namespace.  

Original comment by jan.g...@gmail.com on 11 May 2014 at 1:07

GoogleCodeExporter commented 9 years ago
I can't really tell from your code what is going on.

Whatever is going on with namespaces, can't have anything to do with Objectify. 
Objectify has no knowledge of namespaces and has no code to manipulate them. 
GAE stores the "current" namespace as a thread local (actually as an attribute 
in the thread local apiproxy environment). GAE imbues keys with a namespace 
inside the low level api when the key is created. Objectify isn't involved.

Basically, if namespaces aren't working as you expect, the problem is either a 
bug in your code or a bug in the low level API.

If you'd like to open up a discussion on the objectify google group, someone 
might be able to help you. I would start by trying to distill the problem to a 
better-isolated test case.

Original comment by lhori...@gmail.com on 11 May 2014 at 6:01

GoogleCodeExporter commented 9 years ago
Yes. Indeed. This has nothing to do with objectify:) The issue on my side was 
in that the key of the entity was created in default namespace. Thus setting 
namespaces had no  effect. Thanks for the prompt response.

Original comment by jan.g...@gmail.com on 11 May 2014 at 8:41