On Wed, Jun 24, 2015 at 12:49 PM, <[email protected]> wrote: > we are in testing phase of our application , > so we have to database > 1. live database > 2. test database. > > so can anyone please suggest a way to dynamically switch from live > database to test database , > for now we have created 2 different source code and have created 2 > instance of application, but we want to keep the source code same. >
Personally, I would use *namespaces* for this -- so the "two" databases are really just one, but segregated. (If your use of the datastore already involve namespaces for other reasons, just *prefix* e.g "test-" to the namespace you'd otherwise be using, if you're "just testing"). As for doing the switch "dynamically", it depends on what exactly you mean by that -- e.g, if you mean that your app receives a signal of some kind (for example a POST to an HTTPS admin-only special control URL) and must then switch "correctly", careful design is likely to be needed to determine what happens to already-started queries, tasks in queues, &c -- presumably those need to run to completion with whatever DB they've been started with, but *new* incoming ones must use the DB that's just been set, which is *not* a trivial problem in terms of architecting things. However this would apply *no matter what* mens you used to address the GAE-specific issue of "switching" -- the problem is with the "dynamically" part, as I just tried to interpret it, and it's an architectural problem you'd have to face in any such cases (e.g imagine instead of the datastore you were using two CloudSQL DBs at different URLs -- very different technology but exactly the same architectural issues arise, showing it's a problem of exact requirements and of architecture, *not* in any way GAE-specific). If you can arrange things so that each incoming query specifically marks itself as a "test" one if it is, the server-side architecture becomes trivial -- but this moves the difficulty to the client side. E.g, you might have two versions of your app (with the same source code) or otherwise different URLs. One mixed architecture might involve queries to your app being "tagged" as test or not as they come in and carrying that key bit of state around for each query's life (with tasks spawned from queries also "inheriting" it) -- it could be mixed with the idea in the previous paragraph via e.g redirects, or via dispatching within your code, depending on what framework you're using (how dynamical it lets the actual dispatching be). If you specify very precisely what you mean by "dynamically", perhaps correspondingly more precise architectural suggestions can be offered. Alex > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-appengine. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/c75c499d-9cf4-405f-95d6-bb228949e7ed%40googlegroups.com > <https://groups.google.com/d/msgid/google-appengine/c75c499d-9cf4-405f-95d6-bb228949e7ed%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CAE46Be-jx%2B1qnCLMRzYmSpSkPgh_Rr8H%2BG0Wyh-0vUViKcLqrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
