Group items tagged

Queries involving keys use indexes just like queries involving properties. Queries on keys require custom indexes in the same cases as with properties, with a couple of exceptions: inequality filters or an ascending sort order on __key__ do not require a custom index, but a descending sort order on __key__ does. As with all queries, the development web server creates appropriate configuration entries in this file when a query that needs a custom index is tested.

we can build the start of an open source App Engine server clone that's suitable for many purposes:  initially just for regression testing & local development (like the "dev_appserver" that comes with the App Engine Python SDK), but perhaps in the future (once Hypertable/Hbase/etc are ready) a full stack to give to ISPs to let them run App Engine apps on their own.

disabling session id in code will not stop the cookie from saving session id. When you enable session in app engine xml file than you are telling the framework that you don't want to save sessions in cookies (client side), instead you want to save them on server i.e. using _ah_session. Cookies JSession id is default behavior of Java session mgmt. And it is nothing to do with APP engine framework.*

This tutorial concerns using Google Accounts to maintain the existence of your users in a Google App Engine application. Google App Engine provides the class UserServiceFactory to facilitate that. UserServiceFactory is then used to generate UserService object, which in turn provides the following features createLoginURL createLogoutURL getCurrentUser isUserAdmin isUserLoggedIn You would use UserService object to generate the login URL for the browser. The browser would be directed/redirected to this URL. On reaching this URL, the Google log-in prompt would be displayed by Google's server.

The remote_api module consists of two parts: A 'handler', which you install on the server to handle remote datastore requests, and a 'stub', which you set up on the client to translate datastore requests into calls to the remote handler. remote_api works at the lowest level of the datastore, so once you've set up the stub, you don't have to worry about the fact that you're operating on a remote datastore: With a few caveats, it works exactly the same as if you were accessing the datastore directly.

Note that the handler specifies "login: admin". This is extremely important, since we don't want to give just anyone unfettered access to our datastore!

Since you're accessing the datastore over HTTP, there's a bit more overhead and latency than when you access it locally. In order to speed things up and decrease load, try to limit the number of round-trips you do by batching gets and puts, and fetching batches of entities from queries. This is good advice not just for remote_api, but for using the datastore in general, since a batch operation is only considered to be a single Datastore operation

there are few jars like appengine-testing.jar appengine-local-rutime-shared.jar etc. Basically when you create a new GAE project the eclipse plugin copies some jars automatically in war folder, which are required when you will be running ur application on GAE server, but it doesnt copy few test jars which are required only for local dev env and testing. So what i did i compared jars in my war folder and GAE SDK installed folder. I found that few of jars not included so i included all in my Eclipse build path/Junit run path(but didnt copy into war folder) and that worked for me and then i didnt care to check which were the jars actually needed and which were not as i included all jars. But somehow in docs they have mentioned to included only one or two jars and with these jars junit doesnt work.

This article studies the proxy technique first and then turns to the Google AJAX Feed API method, giving you a chance to intermix Java™and JavaScript coding.

You need a service that, when given a feed URL, connects to that site, downloads its contents, and sends them back to the caller. (For a shell-line parallel, consider the wget or curl command.) You can do this many ways, and Listing 2 shows a simple way to accomplish the task. Because I decided to call my remote proxy RemoteProxy, the server-side class had to be called RemoteProxyImpl; Impl stands for "Implementation."

The SOP won't let your code get data from another site, but there's an exception: You can download and execute JavaScript code using the <script ... /> tag. If the code you download happens to include data and calls a function of yours that puts the data to good use, then you have managed to bypass the SOP. Here's the idea behind the Google AJAX Feed API: It uses the <script ... /> tag to call a Google site that works as a proxy. The remote site gets the feed data and returns it in the form of JavaScript code. The downloaded JavaScript code calls your function so you can process the incoming XML

It turns out that the Content-Type is also affecting the servers decision to compress the response. We were using applicaton/xml as Content-Type and when changing this to text/xml, the compression was enabled.

Please support the ability to server static files from the runtime based on regex patterns similar to the current Python runtime. Currently the only way to simulate this functionality is with a servlet. This is not ideal peformance, as evidenced by existing special handling of static files. The most compelling use case is for versioning static files with the app's version ID so that browsers can maximally cache static files without experiencing stale caches later when the app is updated.

The war/ directory uses the WAR standard layout for bundling web applications. (WAR archive files are not yet supported by the SDK.) The Eclipse plugin uses this directory for running the development server, and for deploying the app to App Engine. When Eclipse builds your project, it creates a directory named classes/ in war/WEB-INF/, and puts compiled class files here. Eclipse also copies non-source files found in src/ to war/WEB-INF/classes/, including META-INF/ and the log4j.properties and logging.properties files. The final contents of the war/ directory make up your application for testing and deployment. For details about the new project that the plugin creates, see the Getting Started Guide.