hi Lars
Would this help you/ http://code.google.com/appengine/docs/java/users/
On Jul 26, 10:19 pm, vogella wrote:
> Hi,
>
> I have a small Todo application written. I would like to use the Mail
> service to receive new todos items via email.
>
> I can get the sender of the email via getFrom()
Hello,
I am sorry for my late answer. I am trying to implement kind of
authorization
system to access certain service. This service is only available for
example
X times per Y seconds (x = 5, y = 60 * 15)
each request to this service is identified by uniqueID so I know who
is asking the service
Thanks, Don. It works like a charm after I include below line in html.
On Jul 26, 11:03 pm, Don Schwarz wrote:
> Yes, this feature isn't launched in the production server yet.
>
> You can try it out in the 1.3.5 DevAppServer, but it requires a slightly
> workaround:
>
> Extract the "apphosting/t
Hi,
I have a small Todo application written. I would like to use the Mail
service to receive new todos items via email.
I can get the sender of the email via getFrom() and would like to map
this to the user in my application and create a new Todo for this
user.
Is it possible to retrieve the use
Thanks for the update Jake.
On Jul 26, 8:24 pm, Jake wrote:
> Hey,
>
> Yes, sessions are stored in the datastore, make use of the memcache,
> and behave as expected regardless of which instances are serving your
> user. However, you still face the same 1MB limit and this system,
> obviously, onl
On 27 Jul 2010, at 00:24, Bill wrote:
This would completely disregard my business model. A Domain is not an
Element, nor vice-versa. It's something analogous to making both
classes Elephant and Corn implement the same interface because both
have Ears.
Ha ha well you would not actually need t
Hey,
Yes, sessions are stored in the datastore, make use of the memcache,
and behave as expected regardless of which instances are serving your
user. However, you still face the same 1MB limit and this system,
obviously, only applies to values saved in the session; any class or
application variab
Hi John,
> Are all Element "trees" in the same domain?
Yes they are.
> If so then you could make
> Domain implement Element and use it as the root of an element
> hierarchy.
This would completely disregard my business model. A Domain is not an
Element, nor vice-versa. It's something anal
It is misleading to suggest DWR 3.0RC1 is fully compatible with google
app engine. See here:
http://groups.google.com/group/google-appengine-java/browse_thread/thread/8db782c90827d825?pli=1
and here: http://old.nabble.com/DWR3RC1-threads-to23074328.html#a23074328
for more info
--
You received th
Sorry...i have posted multiple times same content.
My mistake.
On 26 Lug, 17:08, salvatore wrote:
> :-(
> As you can see here
>
> http://code.google.com/intl/it-IT/appengine/docs/java/javadoc/com/goo...
> Gae low level API don't support, query.setParameter(...)
> there are some other solutions?
>
:-(
As you can see here
http://code.google.com/intl/it-IT/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Query.html
Gae low level API don't support, query.setParameter(...)
there are some other solutions?
(tank's for the answer Tony)
On 25 Lug, 16:14, Tony Qiu wrote:
> Of course
:-(
As you can see here
http://code.google.com/intl/it-IT/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Query.html
Gae low level API don't support, query.setParameter(...)
there are some other solutions?
(tank's for the answer Tony)
On 25 Lug, 16:14, Tony Qiu wrote:
> Of course
:-(
As you can see here
http://code.google.com/intl/it-IT/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Query.html
Gae low level API don't support, query.setParameter(...)
there are some other solutions?
(tank's for the answer Tony)
On 25 Lug, 16:14, Tony Qiu wrote:
> Of course
Yes, this feature isn't launched in the production server yet.
You can try it out in the 1.3.5 DevAppServer, but it requires a slightly
workaround:
Extract the "apphosting/tools/dev-channel-js.js" file from
appengine-api-1.0-sdk-1.3.5.jar and move it to /_ah/channel/jsapi in your
war directory (a
The Channel API is not yet publicly launched. However, most of the
DevAppServer support was in 1.3.5.
Here's a workaround if you want to test it out:
Extract the "apphosting/tools/dev-channel-js.js" file from
appengine-api-1.0-sdk-1.3.5.jar and move it to /_ah/channel/jsapi in your
war directory
On 26 Jul 2010, at 19:21, Bill wrote:
Good thought, but unforunately Elements already have a parent key in
this manner. Elements are hierarchical, so that an Element's parent
is another parent.
Can an entity have more than one parent? I haven't tried that...
An Entity can only have one pa
I think it's not possible to have more than one parent entity.
I'm sure this is not possible using Keys, I don't know if it's the
case for Strings but I think the same applies there.
Adding another parent to the code shown (which should work) results in
an exception using datastore Keys.
I think
* should read, "Elements are hierarchical, so that an Element's parent
is another Element, or else it is a root."
--
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 google-appengine-j...@googlegro
Good thought, but unforunately Elements already have a parent key in
this manner. Elements are hierarchical, so that an Element's parent
is another parent.
Can an entity have more than one parent? I haven't tried that...
For more reference, here are all the fields that might be of interest
to
Well, this is one of the major (maybe THE) drawback in
appengine...apps architecture must be designed for the platform much
more than with other kind of solutions.
Thinking a bit more about the original problem, there's a simple
solution for all: you can simply put your Domain Key in each element,
You need to read your Blob's content in several chunks
that are no larger than the limit.
Combining this with XML file compression can also make sense.
On Jul 25, 9:07 pm, korey_sed wrote:
> I am stumped. No matter what API call I try to read a large blob, I
> get the following:
>
> Caused by: c
Hi Fixou,
Try replacing this line:
Query query = Device.getPersistenceManager().newQuery(sqlFetchAll);
with this:
Query query = Device.getPersistenceManager().newQuery(Device.class);
eliminating the "String sqlFetchAll" line. I use this approach and it
works for me.
On Jul 25, 3:23 pm, Fixo
Hi Lorenzo,
Certainly, this would work from a technical perspective. However, it
is absolutely not right for the problem. For a variety of reasons,
Domain and Element need to have a completely unowned relationship.
I'll explain some of my high-level situation:
The Domain will be administered b
So GAE makes sure the preserve session data between shutting down/
starting up instances. Nice.
On Jul 26, 12:44 pm, Shawn Brown wrote:
> > What happens if between logged in user navigates to another page and
> > the GAE instance was shutdown?
> > I understand a new instance is started but what
> What happens if between logged in user navigates to another page and
> the GAE instance was shutdown?
> I understand a new instance is started but what happened to the
> session data?
AFAIK session data is persisted to big table.
> Also, how is startup/shutdown of instances related to session-t
I like to store the logged in user (custom; not Google User Api) of my
app in the session.
What happens if between logged in user navigates to another page and
the GAE instance was shutdown?
I understand a new instance is started but what happened to the
session data?
Also, how is startup/shutdow
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 elements;
}
This works correctly and you get the benefit to have a cascasing
delete on elements w
27 matches
Mail list logo
