[google-appengine] Re: Closure and Google App Engine
Hi Adrian, Are you referring to the recently-released Closure JavaScript library? The intention is that you use it with Closure Compiler, producing a single script you can include with your app, so there's no need to include the entire thing. -Nick Johnson On Fri, Nov 6, 2009 at 6:18 PM, acuth wrote: > > The Closure library download is 149MB and 2,933 files. I don't really > want to have that as a static dir in GAE. Does Google host it anywhere > so it can be referenced from a GAE app? > > > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
Hi Nick, There are a certain class of applications that modify their code at runtime - is the intention that these use the restful Closure JavaScript compiler API? One of the downsides to GWT is the need for compilation (there's no compiler on GAE) - also making this a *requirement* of a straight javascript solution takes away the 'dynamic' part of a 'dynamic language', and turns it into, well, just a language. The Closure JavaScript library does allow us to run without compilation, so we can use it dynamically, but as the original poster noted, it takes up some pretty serious space - it would be great to see google host this on a CDN to support this alongside the compiled scenario. Thanks, colin On Nov 7, 10:03 pm, "Nick Johnson (Google)" wrote: > Hi Adrian, > > Are you referring to the recently-released Closure JavaScript library? The > intention is that you use it with Closure Compiler, producing a single > script you can include with your app, so there's no need to include the > entire thing. > > -Nick Johnson > > On Fri, Nov 6, 2009 at 6:18 PM, acuth wrote: > > > The Closure library download is 149MB and 2,933 files. I don't really > > want to have that as a static dir in GAE. Does Google host it anywhere > > so it can be referenced from a GAE app? > > -- > Nick Johnson, Developer Programs Engineer, App Engine > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Thoughts on pagination with GAE
> I'd rather not pass the ID of the next object because then I'd have to > do a datastore get in order to get its date. Memcache! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Thoughts on pagination with GAE
2009/11/6 wings: > > > What I would really like to discover is a solution that is: ... wouldnt we all! I'm not sure its been determined that a 'true' solution exists. ;P Or at least a simple one. And one that works on massive datasets, like AppEngine is meant to support. Coming from mysql, its easy to think paging is a simple issue. Just use a Count(*) and LIMIT on the queries. But that doesn't scale, its horribly slow (but usually fast enough on small datasets) In fact it reminds me of a saying I recently saw in a book: "Fast, Accurate, Simple: pick any two" Also re the 'previous' page link, memcache (again)! Store the 'cursor' of each page in memcache (as you calculate it), and then on a page, you can check memcache for cursor you need for the back link. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: gql not giving full result set
just a guess:
"An index only contains entities that have every property referred to
by the index."
http://bit.ly/qiTBk
that my be the reason, why you get a different number of results
On Nov 6, 6:53 pm, Adhi wrote:
> Yes, I've tried using order by also. But its giving different
> resultset.
> When using order by I got only 842 records, but with out order by I
> got 1251
> where as my actual records will be >1260. and when I change the fetch
> size
> I'm getting different count.
>
> Here is my code...
>
> def get_serialized_data(entityClass, params):
> query = entityClass.all()
> query.order('__key__')
>
> for filterColumn, filterValue in params.iteritems():
> query.filter(filterColumn, filterValue)
> limit = 400
> offset = 0
> totalLimit = 800
> lastRecordKey = None
> n = 0
> entities = query.fetch(limit, offset)
> while entities and offset <= (totalLimit-limit):
> lastRecordKey = entities[-1].key()
> n += len(entities)
> # My serialization code here
> offset+=limit
> if len(entities)==limit:
> entities = query.fetch(limit, offset)
> else:
> entities = None
> entities = None
> return (n>=totalLimit, lastRecordKey)
>
> def download_data():
> params = {'ApplicationId':applicationId, 'Deleted':False,
> 'SheetMetadataId':'Sheet003'}
> (moreRecords, lastRecordKey) = get_serialized_data(PrimaryData,
> params)
> while moreRecords:
> params['__key__ >'] = lastRecordKey
> (moreRecords, lastRecordKey) = get_serialized_data
> (PrimaryData, params)
>
> download_data()
>
> Each batch will fetch 800 records if I use q.fetch(800) its giving
> Timeout so I've used offset.
> As per the documentation
> inhttp://code.google.com/appengine/articles/remote_api.html
> they haven't specified
> to add order by for __key__ so I thought its implicit. Thats why I
> initially tried with out order by.
> Am I doing anything wrong?
>
> Now I'm trying to delete and recreating the indexes because of this
> problem, but it still in deleting state.
>
> Adhi
>
> On Nov 6, 7:13 pm, Eli Jones wrote:
>
> > Always post a full code snippet.
>
> > Aren't you supposed to use Order By when paging by key?
>
> > On 11/6/09, Adhi wrote:
>
> > > Hi,
> > > Sometimes I am not getting the complete resultset fromgqleven though
> > > the missing records satisfies the condition. I've proper indexes.
> > > Total records for that query will be around 1300. So, I'm not fetching
> > > the records in a single fetch, I'm using __key__ > last_record_key to
> > > get in batches.
>
> > > Why is this anomaly..? anything I am missing here.
>
> > > Adhi
>
> > --
> > Sent from my mobile device
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
On Sat, Nov 7, 2009 at 12:38 PM, hawkett wrote: > > Hi Nick, > > There are a certain class of applications that modify their code at > runtime - is the intention that these use the restful Closure > JavaScript compiler API? What sort of runtime modification are you talking about? > One of the downsides to GWT is the need for > compilation (there's no compiler on GAE) - also making this a > *requirement* of a straight javascript solution takes away the > 'dynamic' part of a 'dynamic language', and turns it into, well, just > a language. Not at all - all the dynamic features of Javascript are available to you, whether you use the Closure library compiled or not. > The Closure JavaScript library does allow us to run > without compilation, so we can use it dynamically, but as the original > poster noted, it takes up some pretty serious space - it would be > great to see google host this on a CDN to support this alongside the > compiled scenario. Thanks, > Apart from any issues with hosting, serving a production webapp with the uncompiled closure code will substantially slow things down for your users, as they are required to load (potentially) tens of javascript files instead of just a single one. -Nick Johnson > > colin > > On Nov 7, 10:03 pm, "Nick Johnson (Google)" > wrote: > > Hi Adrian, > > > > Are you referring to the recently-released Closure JavaScript library? > The > > intention is that you use it with Closure Compiler, producing a single > > script you can include with your app, so there's no need to include the > > entire thing. > > > > -Nick Johnson > > > > On Fri, Nov 6, 2009 at 6:18 PM, acuth wrote: > > > > > The Closure library download is 149MB and 2,933 files. I don't really > > > want to have that as a static dir in GAE. Does Google host it anywhere > > > so it can be referenced from a GAE app? > > > > -- > > Nick Johnson, Developer Programs Engineer, App Engine > > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration > Number: > > 368047 > > > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
> What sort of runtime modification are you talking about? A user changes a piece of javascript, or adds a piece of javascript - for the sake of the example lets assume the javascript is stored in the GAE datastore. Something that you get from javascript, and precisely because it doesn't require compilation, is the ability to press refresh on your browser and see the changes take effect. The only opportunity to compile here appears to be via the rest api - do you know if this api is suitable for GAE (e.g. execution timeouts could be a problem via URL Fetch?). > Not at all - all the dynamic features of Javascript are available to you, > whether you use the Closure library compiled or not. Lets look at a widely available definition of a dynamic language http://en.wikipedia.org/wiki/Dynamic_programming_language '...that execute at runtime many common behaviors that other languages might perform during compilation,...' The first feature listed there is 'Extension of the program'. Lets assume my extension requires a google closure api that has not been compiled in. If I'm not hosting the closure library on GAE, and it's not on a CDN, then I need some other hosting solution, or I need to recompile everything. Clearly requiring a compilation phase does not retain all of the dynamic language features of javascript. From one perspective, linking is performed by the closure compiler when traditionally it was performed by the browser at runtime. Of course compilation offers performance improvements, but in return you suffer a loss of dynamic language flexibility - its a well understood trade-off. With Closure, google is offering a solution that supports both static and dynamic linking, but without the CDN, the latter option has (even greater) performance problems. Unless you're suggesting that there is no valid use case for retaining dynamic linking (in production or otherwise), then there is a clear benefit to a fast, reliable and free host for the google Closure Library. I would argue that there are some valid, and highly valuable use cases that *require* dynamic linking, at runtime, in production. > Apart from any issues with hosting, serving a production webapp with the > uncompiled closure code will substantially slow things down for your users, > as they are required to load (potentially) tens of javascript files instead > of just a single one. No doubt, but this is exactly the reason a CDN would be a welcome offering. This, combined with effective browser caching go a long way to mitigating these performance issues in applications that need to retain the dynamic linking capabilities of javascript. Don't get me wrong, the release of the closure library is awesome, and very much appreciated, but not all use cases are suited to compiled javascript, while others would be suited to a combination of both. Access to a CDN, (and to a compiler accessible and useable from GAE) would be really helpful. Thanks, colin On Nov 8, 2:15 am, "Nick Johnson (Google)" wrote: > On Sat, Nov 7, 2009 at 12:38 PM, hawkett wrote: > > > Hi Nick, > > > There are a certain class of applications that modify their code at > > runtime - is the intention that these use the restful Closure > > JavaScript compiler API? > > What sort of runtime modification are you talking about? > > > One of the downsides to GWT is the need for > > compilation (there's no compiler on GAE) - also making this a > > *requirement* of a straight javascript solution takes away the > > 'dynamic' part of a 'dynamic language', and turns it into, well, just > > a language. > > Not at all - all the dynamic features of Javascript are available to you, > whether you use the Closure library compiled or not. > > > The Closure JavaScript library does allow us to run > > without compilation, so we can use it dynamically, but as the original > > poster noted, it takes up some pretty serious space - it would be > > great to see google host this on a CDN to support this alongside the > > compiled scenario. Thanks, > > Apart from any issues with hosting, serving a production webapp with the > uncompiled closure code will substantially slow things down for your users, > as they are required to load (potentially) tens of javascript files instead > of just a single one. > > -Nick Johnson > > > > > > > > > colin > > > On Nov 7, 10:03 pm, "Nick Johnson (Google)" > > wrote: > > > Hi Adrian, > > > > Are you referring to the recently-released Closure JavaScript library? > > The > > > intention is that you use it with Closure Compiler, producing a single > > > script you can include with your app, so there's no need to include the > > > entire thing. > > > > -Nick Johnson > > > > On Fri, Nov 6, 2009 at 6:18 PM, acuth wrote: > > > > > The Closure library download is 149MB and 2,933 files. I don't really > > > > want to have that as a static dir in GAE. Does Google host it anywhere > > > > so it can be referenced from a GAE app? > > > > -- > > > Nick Johnson, D
[google-appengine] Querys
Hello,
How can I know how many items it returns a query?
Example:
eventos = db.GqlQuery ("SELECT * FROM Evento")
How many items?
Other question.
How can I do random of numers in python?
See you. Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
2009/11/7 hawkett : > >> What sort of runtime modification are you talking about? > > A user changes a piece of javascript, or adds a piece of javascript - > for the sake of the example lets assume the javascript is stored in > the GAE datastore. Something that you get from javascript, and > precisely because it doesn't require compilation, is the ability to > press refresh on your browser and see the changes take effect. The > only opportunity to compile here appears to be via the rest api - do > you know if this api is suitable for GAE (e.g. execution timeouts > could be a problem via URL Fetch?). Surely you talking about the closure *compiler*, not the closure *library* here Admittedly my java is rusty, so dont know if you can use the provided jar directly from (java!) appengine code. But downloadable as a 4mb jar file so I would think that can be used on appengine. I don't know enough about the library to know if having it accessible in a common location (like Django in python?), would actually be a benefit. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
On Sat, Nov 7, 2009 at 4:18 PM, hawkett wrote: > > > What sort of runtime modification are you talking about? > > A user changes a piece of javascript, or adds a piece of javascript - > for the sake of the example lets assume the javascript is stored in > the GAE datastore. Something that you get from javascript, and > precisely because it doesn't require compilation, is the ability to > press refresh on your browser and see the changes take effect. This is a property of Javascript - but it doesn't mean every library has to abide by that. Closure consciously makes a tradeoff - it abandons a little flexibility in favor of improved responsiveness and smaller downloads. > The > only opportunity to compile here appears to be via the rest api - do > you know if this api is suitable for GAE (e.g. execution timeouts > could be a problem via URL Fetch?). > I'm not familiar with it. Give it a try! > > > Not at all - all the dynamic features of Javascript are available to you, > > whether you use the Closure library compiled or not. > > Lets look at a widely available definition of a dynamic language > > http://en.wikipedia.org/wiki/Dynamic_programming_language > > '...that execute at runtime many common behaviors that other languages > might perform during compilation,...' > > The first feature listed there is 'Extension of the program'. Lets > assume my extension requires a google closure api that has not been > compiled in. If I'm not hosting the closure library on GAE, and it's > not on a CDN, then I need some other hosting solution, or I need to > recompile everything. > Having to recompile a third-party library does not affect whether or not JavaScript is a dynamic language or not. Third-party libraries are certainly not part of the JavaScript language. I think you misunderstand the meaning of 'extend' in context, too - in the context of a dynamic language, this generally means changing the behaviour of the language itself. > > Clearly requiring a compilation phase does not retain all of the > dynamic language features of javascript. From one perspective, > linking is performed by the closure compiler when traditionally it was > performed by the browser at runtime. Of course compilation offers > performance improvements, but in return you suffer a loss of dynamic > language flexibility - its a well understood trade-off. With > Closure, google is offering a solution that supports both static and > dynamic linking, but without the CDN, the latter option has (even > greater) performance problems. > > Unless you're suggesting that there is no valid use case for retaining > dynamic linking (in production or otherwise), then there is a clear > benefit to a fast, reliable and free host for the google Closure > Library. I would argue that there are some valid, and highly valuable > use cases that *require* dynamic linking, at runtime, in production. > You pointed out yourself just how many files and what a large total size the Closure library is. Requiring users to download parts of it un-compiled and un-minified to run your app is likely to make it an extremely slow app. I don't think many people will be willing to make that tradeoff. > > Apart from any issues with hosting, serving a production webapp with the > > uncompiled closure code will substantially slow things down for your > users, > > as they are required to load (potentially) tens of javascript files > instead > > of just a single one. > > No doubt, but this is exactly the reason a CDN would be a welcome > offering. This, combined with effective browser caching go a long way > to mitigating these performance issues in applications that need to > retain the dynamic linking capabilities of javascript. > > Don't get me wrong, the release of the closure library is awesome, and > very much appreciated, but not all use cases are suited to compiled > javascript, while others would be suited to a combination of both. > Access to a CDN, (and to a compiler accessible and useable from GAE) > would be really helpful. Thanks, > > colin > > On Nov 8, 2:15 am, "Nick Johnson (Google)" > wrote: > > On Sat, Nov 7, 2009 at 12:38 PM, hawkett wrote: > > > > > Hi Nick, > > > > > There are a certain class of applications that modify their code at > > > runtime - is the intention that these use the restful Closure > > > JavaScript compiler API? > > > > What sort of runtime modification are you talking about? > > > > > One of the downsides to GWT is the need for > > > compilation (there's no compiler on GAE) - also making this a > > > *requirement* of a straight javascript solution takes away the > > > 'dynamic' part of a 'dynamic language', and turns it into, well, just > > > a language. > > > > Not at all - all the dynamic features of Javascript are available to you, > > whether you use the Closure library compiled or not. > > > > > The Closure JavaScript library does allow us to run > > > without compilation, so we can use it dynamically, but as th
[google-appengine] Re: Closure and Google App Engine
> Surely you talking about the closure *compiler*, not the closure *library* > here Both. Nick's point (as I read it) is that you shouldn't be using one without the other, at least not in production, and my point is that there are valid situations in which you do want the library and not the compiler, and thus the availability of a fast, reliable and free host for the closure library files would be welcome. On Nov 8, 4:05 am, Barry Hunter wrote: > 2009/11/7 hawkett : > > > > >> What sort of runtime modification are you talking about? > > > A user changes a piece of javascript, or adds a piece of javascript - > > for the sake of the example lets assume the javascript is stored in > > the GAE datastore. Something that you get from javascript, and > > precisely because it doesn't require compilation, is the ability to > > press refresh on your browser and see the changes take effect. The > > only opportunity to compile here appears to be via the rest api - do > > you know if this api is suitable for GAE (e.g. execution timeouts > > could be a problem via URL Fetch?). > > Surely you talking about the closure *compiler*, not the closure *library* > here > > Admittedly my java is rusty, so dont know if you can use the provided > jar directly from (java!) appengine code. But downloadable as a 4mb > jar file so I would think that can be used on appengine. > > I don't know enough about the library to know if having it accessible > in a common location (like Django in python?), would actually be a > benefit. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Closure and Google App Engine
> Closure consciously makes a tradeoff - it abandons a little > flexibility in favor of improved responsiveness and smaller downloads. I think we've both made that point about compilation. Unfortunately it could be a gazillion times faster, better, stronger, cooler, but it still won't be suitable for all use cases - no matter how many times you wish it otherwise. For those use cases the performance benefits of compilation are irrelevant, because compilation is not suitable. Here's an example of a production application for which it would not be suitable - http://code.google.com/apis/ajax/playground/ - and, what's more, the users of this application are probably okay to wait the extra time to be able to use closure *dynamically*. I'm sure they'd really appreciate getting it to load as fast as possible though, by say, putting it on a fast, highly available server. The problem is not always as simple as 'compilation is better so do it'. Perhaps you're saying - 'If you don't want to compile, don't use closure', but then I guess we won't see it on the ajax playground. > You pointed out yourself just how many files and what a large total size the > Closure library is. Requiring users to download parts of it un-compiled and > un-minified to run your app is likely to make it an extremely slow app. I > don't think many people will be willing to make that tradeoff Google could minify it on the CDN? Otherwise someone might think you're against this whole CDN idea ;) On Nov 8, 4:58 am, "Nick Johnson (Google)" wrote: > On Sat, Nov 7, 2009 at 4:18 PM, hawkett wrote: > > > > What sort of runtime modification are you talking about? > > > A user changes a piece of javascript, or adds a piece of javascript - > > for the sake of the example lets assume the javascript is stored in > > the GAE datastore. Something that you get from javascript, and > > precisely because it doesn't require compilation, is the ability to > > press refresh on your browser and see the changes take effect. > > This is a property of Javascript - but it doesn't mean every library has to > abide by that. Closure consciously makes a tradeoff - it abandons a little > flexibility in favor of improved responsiveness and smaller downloads. > > > The > > only opportunity to compile here appears to be via the rest api - do > > you know if this api is suitable for GAE (e.g. execution timeouts > > could be a problem via URL Fetch?). > > I'm not familiar with it. Give it a try! > > > > > > > > > > Not at all - all the dynamic features of Javascript are available to you, > > > whether you use the Closure library compiled or not. > > > Lets look at a widely available definition of a dynamic language > > >http://en.wikipedia.org/wiki/Dynamic_programming_language > > > '...that execute at runtime many common behaviors that other languages > > might perform during compilation,...' > > > The first feature listed there is 'Extension of the program'. Lets > > assume my extension requires a google closure api that has not been > > compiled in. If I'm not hosting the closure library on GAE, and it's > > not on a CDN, then I need some other hosting solution, or I need to > > recompile everything. > > Having to recompile a third-party library does not affect whether or not > JavaScript is a dynamic language or not. Third-party libraries are certainly > not part of the JavaScript language. I think you misunderstand the meaning > of 'extend' in context, too - in the context of a dynamic language, this > generally means changing the behaviour of the language itself. > > > > > > > > > Clearly requiring a compilation phase does not retain all of the > > dynamic language features of javascript. From one perspective, > > linking is performed by the closure compiler when traditionally it was > > performed by the browser at runtime. Of course compilation offers > > performance improvements, but in return you suffer a loss of dynamic > > language flexibility - its a well understood trade-off. With > > Closure, google is offering a solution that supports both static and > > dynamic linking, but without the CDN, the latter option has (even > > greater) performance problems. > > > Unless you're suggesting that there is no valid use case for retaining > > dynamic linking (in production or otherwise), then there is a clear > > benefit to a fast, reliable and free host for the google Closure > > Library. I would argue that there are some valid, and highly valuable > > use cases that *require* dynamic linking, at runtime, in production. > > You pointed out yourself just how many files and what a large total size the > Closure library is. Requiring users to download parts of it un-compiled and > un-minified to run your app is likely to make it an extremely slow app. I > don't think many people will be willing to make that tradeoff. > > > > > > > > Apart from any issues with hosting, serving a production webapp with the > > > uncompiled closure code will substantially slow
[google-appengine] Re: Closure and Google App Engine
Just for the record... my initial post was just me wanting to explore using Closure as cheaply as possible. I certainly agree that one would expect to use the Closure Compiler for a production system. But I would have thought that the goog.provide ()/goog.require() mechanism in combination with minified files on a CDN would have been an acceptable model for developers exploring Closure for the first time. Currently everything I have that is publicly hosted is either on Blogger or GAE and I don't think either of those is a natural home for the Closure Library. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Task queue logging stopped?
Right around noon today I stopped getting log messages for my task queue attempts. I can create new tasks, the console says they are being retried, but I don't see the execution request in the logs at all. I can't tell why my tasks are failing :-( Did something change today? Thanks, Jeff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Task queue logging stopped?
Nevermind. Looks like there is a bug in the Task Queue, if you create a Task URL with a (properly urlencoded) newline in it, the executioner silently fails (although the retry count goes up). Jeff On Nov 7, 1:51 pm, Jeff Schnitzer wrote: > Right around noon today I stopped getting log messages for my task > queue attempts. I can create new tasks, the console says they are > being retried, but I don't see the execution request in the logs at > all. I can't tell why my tasks are failing :-( > > Did something change today? > > Thanks, > Jeff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: remote_api intermittantly throwing HTTPError 302 after 100's of transactions (and found bug in apiproxy code
Hi Further to my report about the remote server send HTTPError 302, after a number of remote api calls, the stack trace I am getting suggests that the path in the apiproxy code has a problem as a second exception is raised when the 302 is sent. Traceback (most recent call last): File "/opt/ktstudio/zope/instances/prod/swantafe.buildout/ google_appengine/google/appengine/api/datastore.py", line 1989, in RunInTransactionCustomRetries tx.handle, resp) File "/opt/ktstudio/zope/instances/prod/swantafe.buildout/ google_appengine/google/appengine/api/apiproxy_stub_map.py", line 72, in MakeSyncCall apiproxy.MakeSyncCall(service, call, request, response) File "/opt/ktstudio/zope/instances/prod/swantafe.buildout/ google_appengine/google/appengine/api/apiproxy_stub_map.py", line 266, in MakeSyncCall rpc.CheckSuccess() File "/opt/ktstudio/zope/instances/prod/swantafe.buildout/ google_appengine/google/appengine/api/apiproxy_rpc.py", line 111, in CheckSuccess raise self.exception NameError: global name 'txdata' is not defined My first traceback Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PythonScripts.PythonScript, line 328, in _exec Module None, line 8, in send_uos - - Line 8 Module Products.PlonePSC.tools.psc_manager, line 547, in push_to_appengine Module google.appengine.ext.db, line 1064, in get_or_insert Module google.appengine.api.datastore, line 1884, in RunInTransaction Module google.appengine.api.datastore, line 1982, in RunInTransactionCustomRetries Module google.appengine.ext.db, line 1059, in txn Module google.appengine.ext.db, line 981, in get_by_key_name Module google.appengine.ext.db, line 1180, in get Module google.appengine.api.datastore, line 234, in Get Module google.appengine.api.apiproxy_stub_map, line 72, in MakeSyncCall Module google.appengine.api.apiproxy_stub_map, line 266, in MakeSyncCall Module google.appengine.api.apiproxy_rpc, line 111, in CheckSuccess HTTPError: HTTP Error 302: Found T On Nov 7, 8:53 am, Tim Hoffman wrote: > Hi > > I am using remote_api called by Plone to send content to app engine > (to appspot, not the dev_appserver) > and all goes well. However every once and a while after a few hundred > records have been pushed (could be just a few records or several > hundred - no consistancy here) the remote_api calls starts throughing > HTTPError 302. > > At this point if I wait a little while and (any where from 30 secs up > to a few minutes) and then retry > everything is fine again until, the error gets thrown again. I can't > predict how long I have to wait before it works > again. > > I am having trouble working out how to go about solving this one. > > Any got any ideas > > Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Querys
On Nov 7, 12:00 pm, david wrote:
> Hello,
>
> How can I know how many items it returns a query?
> Example:
> eventos = db.GqlQuery ("SELECT * FROM Evento")
> How many items?
>
> Other question.
> How can I do random of numers in python?
>
> See you. Thanks.
python list size or eventos.count() work or already answered question
best way with more info following link,
http://stackoverflow.com/questions/421751/whats-the-best-way-to-count-results-in-gql
and merging pure python lists using multiple queries is also doable
breaking 1000 limit. where earlier random numbers was discussed:
http://groups.google.com/group/google-appengine/browse_thread/thread/b3b41fb86f62b229/bea0d6a880cf01fa?lnk=gst&q=weibull#bea0d6a880cf01fa
Nick Rosencrantz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] [Python] Reading files with python and open()
Hello Could someone tell me why tis code does't work? [CODE] ROOT_DIR = os.path.dirname(__file__) pageUrl = os.path.join(ROOT_DIR, 'pages/' + pageName + '.html') pageContent = open(pageUrl, 'r').read() [/CODE] i get error message [CODE] IOError: [Errno 2] No such file or directory: '/base/data/home/apps/ warlock24/1.337586579904043005/pages/home.html' [/CODE] where are my files? :( --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: [Python] Reading files with python and open()
On Sat, Nov 7, 2009 at 8:39 AM, warlock24 wrote: > > Hello > > Could someone tell me why tis code does't work? > > [CODE] > ROOT_DIR = os.path.dirname(__file__) > pageUrl = os.path.join(ROOT_DIR, 'pages/' + pageName + '.html') > pageContent = open(pageUrl, 'r').read() > [/CODE] > > i get error message > > [CODE] > IOError: [Errno 2] No such file or directory: '/base/data/home/apps/ > warlock24/1.337586579904043005/pages/home.html' > [/CODE] > > where are my files? :( I would think that would work, but I cook everything in myself; you might just try using a relative directory access instead of absolute, I have heard that works best in GAE. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: remote_api reliably throwing HTTPError 302 after 100's of transactions (and found bug in apiproxy code)
On further investigation I am finding the the remote_api always gets a HTTPError 302 after a number of transactions. The exact number varies. Anywhere from 10's to a few hundred. I wait for around 2min, and then resubmit it works find again. I don't believe this is a time based problem, as I often have a console with an authenticated remote_api session open for hours (if not days) and never fails then next time a perform a fetch/get etc... I wonder if some sort of token from the authentication of the remote_api connection is only valid for a varying number of transactions ? T --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] "Only ancestor queries are allowed inside transactions"
Hi all,
I got this error when I tried to run a query in a transaction, "Only
ancestor queries are allowed inside transactions".
I have a class, C1, whose entities have no ancestors. I want to query a
particular entity from it, modify, and put it back, for example,
item = C1.gql("WHERE p1 = :a AND p2 = :b ORDER BY p2", a = None, b =
23).fetch(1)
item.p1 = sth
item.put()
The above code should run in a transaction. What should I do?
Thanks in advance.
Will
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
