Hi Jeff,
In other words, Twig cannot perform the simple query:
IterableObject foo = ofy.query().ancestor(yourobject);
If you ever want to support something like this, you will need a
registration process.
If you ever want to support true polymorphic queries, you will need a
registration
On 1 Apr 2010, at 12:51, Jeff Schnitzer wrote:
In other words, Twig cannot perform the simple query:
IterableObject foo = ofy.query().ancestor(yourobject);
All queries that are possible with the low-level datastore are
possible with Twig because there are low-level to type-safe bridge
On Thu, Apr 1, 2010 at 12:45 AM, John Patterson jdpatter...@gmail.com wrote:
All queries that are possible with the low-level datastore are possible with
Twig because there are low-level to type-safe bridge methods. So you can
simply do a typeless low-level ancestor query and then get Twig to
On 1 Apr 2010, at 15:04, Jeff Schnitzer wrote:
or you've somehow registered a mapping (typically from Kind, but it
could be any synthetic field) to the java class ahead of time. This
means that
You are making a classic premature optimization mistake.
Twig is built on the principal that it
On 1 Apr 2010, at 14:58, Jeff Schnitzer wrote:
If you go with #2, you've just created a framework that will break
your datastore when you rename your Java objects. I'll assume nobody
thinks this is actually a good idea.
From a quick browse of the Objectify source code it looks to me like
On Thu, Apr 1, 2010 at 1:57 AM, John Patterson jdpatter...@gmail.com wrote:
You are making a classic premature optimization mistake.
[...]
The only String value that can uniquely identify a class with no
registration is its fully qualified type name. I see no problem using
that kind name as
On Thu, Apr 1, 2010 at 2:19 AM, John Patterson jdpatter...@gmail.com wrote:
From a quick browse of the Objectify source code it looks to me like the
default is to use Class.getSimpleName() for the kind name which will also
break on renaming and doesn't even have the advantage of working
On 1 Apr 2010, at 16:20, Jeff Schnitzer wrote:
1) I vehemently disagree that fully-qualified java class names should
show up in the datastore. It's one of those things that nobody
notices at the beginning and then becomes cruft that is difficult to
change sometime later. Ask any DBA what
On 1 Apr 2010, at 16:26, Jeff Schnitzer wrote:
On Thu, Apr 1, 2010 at 2:19 AM, John Patterson
jdpatter...@gmail.com wrote:
From a quick browse of the Objectify source code it looks to me
like the
default is to use Class.getSimpleName() for the kind name which
will also
break on
Hi:
On Wed, 2010-03-31 at 22:51 -0700, Jeff Schnitzer wrote:
On Wed, Mar 31, 2010 at 6:41 PM, jd jdpatter...@gmail.com wrote:
On Apr 1, 3:14 am, Jeff Schnitzer j...@infohazard.org wrote:
What does Twig do when someone issues a type-less query?
datastore.find().addFilter(color, EQUAL,
On 1 Apr 2010, at 19:02, Duong BaTien wrote:
Hi:
IterableObject foo = ofy.query().ancestor(yourobject);
This is the required pattern shown in Google IO scalable application
for
GAE.
If you are talking about the million fan out problem in Bret
Slatkins talk that was also a typed
David, Ikai:
Thanks very much for those blog posts on reducing the cold start
time. I think 1 to 2 seconds is reasonable. I'm definitely going to
take a closer look at Objectify.
++Steve
On Mar 30, 4:54 pm, Ikai L (Google) ika...@google.com wrote:
David, that post mirrors many of the points
Yeah, that blog post was awesome. I started moving to Twig last night.
I understand and appreciate the concerns of others that frameworks are
our friends, and that it's not unreasonable to use them, but at the
same time, CPU and network optimization are even more important, so
long as the barrier
On 31 Mar 2010, at 17:58, Blake Caldwell wrote:
From the few hours I've spent with Twig, it seems easier - not
harder than JDO for everything I'm doing.
Nice to hear. You should get improved in ease of use from all of the
non-standard persistence interfaces designed specifically at the
looks interesting. I think I will give this a try.
Can someone give any advice on doing full-text search over datastore
entities? Compass+lucene is by far the heaviest part of my application.
On Wed, Mar 31, 2010 at 3:36 PM, John Patterson jdpatter...@gmail.comwrote:
On 31 Mar 2010, at 17:58,
Here is some more insight. http://bit.ly/d2lOnv
Looks like I was way off on numbers for Grails. Like I said, We should
think less about work arounds, and frameworks-on-diet (not that they
dont work) and rather look at an out of box solution.
-Sarath.
On Mar 31, 2:29 am, Sarath
Blake,
The versions I have are primarily bare. And only used to measure bare
minimum *cold start up time*. The benchmark is ONLY for startup-time
measurement. And to show that the more (and heavy) libraries you add,
The more is the cold startup time. And THAT could be delt with other
technical
On Wed, Mar 31, 2010 at 6:36 AM, John Patterson jdpatter...@gmail.com wrote:
Unlike some of the other frameworks there is no registration process for
your data model classes - each class is analyzed the first time it is used
per server instance and the meta-data is cached for the duration of
On Wed, Mar 31, 2010 at 6:41 PM, jd jdpatter...@gmail.com wrote:
On Apr 1, 3:14 am, Jeff Schnitzer j...@infohazard.org wrote:
What does Twig do when someone issues a type-less query?
datastore.find().addFilter(color, EQUAL, green). returnResultsNow()
The expression above is actually not
Well, both Baz and Shawn are correct.
Shawn is correct from the economical point of view. Baz is correct from the
techinical point of view (no sane user would wait 15 seconds for a page to
appear, right?).
The great thing is that both can be done at the same time. Warmed instances
can be brought
Shawn,
By the same token google could cut all their hardware in half and double
page loads, check out this formula:
NumberOfRequests / HardwareQuality = PageLoad
Therefore, Google should power the entire GAE infrastructure with a netbook
- yes each page would take 2.5 decades to load, but
We're still working through the details of reserved instances. The
constructive feedback on this thread is useful; it is theoretically possible
to pay for an unused instance that requests spill into when they go over
capacity of the current spun up requests. That is - pay for one more
instance
Great information, Ikai.
I really feel that instances should be completely avoided in concept and
language on the GAE. What if the feature was simply an enable/disable deal
called Warm Scale. If it were enabled, then your *next* instance would
always be warm, regardless of how many instances you
In the mean time, here are some ideas for reducing startup times by
shrinking our apps. I went from 8.1s to 2.5s mainly by eliminating
Guice, and I would expect similar results with Spring. I can
definitely live with 2.5s...
David, that post mirrors many of the points made here:
http://www.answercow.com/2010/03/google-app-engine-cold-start-guide-for.html
There's one or two more tips on that page.
On Tue, Mar 30, 2010 at 12:47 PM, David Chandler turboman...@gmail.comwrote:
In the mean time, here are some ideas for
This is getting really interesting. I have been follwoing this post
from a couple of days.
I managed to see What exactly is ammounting to delayed startup.
Some have suggested to remove spring/di/jpa/jdo. While this is true,
it solves much of the problem - These are the reason why I would
choose
Hah, Blake, guess you caught us! We might be doing more stuff with that in
addition to what went out with 1.3.2.
On Fri, Mar 26, 2010 at 6:50 PM, Blake blakecaldw...@gmail.com wrote:
Ikai - that's awesome - great to see you guys listening to us. Is
that doc already outdated? Didn't you just
JohnJ,
The way I see it, you just need to pay for one warmed instance.
I've measured that one instance is enough to handle 30 requests per second.
Trying to execute more requests than that immediatly triggers the loading of
a new instance and so far some of the requests fail.
Therefore, If you
Warmed instances make absolutely no sense on the GAE! It's supposed to be an
invisible, infinite, platform without the notion of ram, cpu's, drives or
instances - it goes completely against the heart and soul of the project.
That just makes us an Amazon. It's boggled my mind from day 1 why
It's boggled my mind from day 1 why instances
aren't loaded in the background. I always assumed it would be addressed
What is difficult to understand?
1 server has X resources
warmed instanced require Y resources
X - YN = resources left over for the server to fulfill requests.
By reducing
30 matches
Mail list logo
