[google-appengine] Re: class_for_kind
It should not be necessary to create new instances for each model you want to use in the class --> kind map. You merely need to define your classes before you use it. So, if you defined a Model called Foo and put it in the models.py module, you would call: import models If you are trying to use class_for_kind in the file where Foo is defined, but Foo is defined after that call, you need to move the definition of Foo up above your function call. Hope that helps. - Rafe On Aug 27, 9:32 am, conman <[EMAIL PROTECTED]> wrote: > Hello, > > I wrote a convenient admin interface which often uses > > db.class_for_kind(model_idf) > > where model_idf is the name of the model class I want to examine. > > But when running on appspot I often got a kind error at this statement > because datastore seemed to not know the entity until at least one had > been created. > > So when deploying on appspot I created dummy entities for every kind > of model - but datastore continues giving me a kind error from time to > time. > > Is it possible that this has something to do with threading..? > Maybe the model class is known only to one thread and the other thread > doesn't know about it? > > Any suggestions? > > Regards, > Constantin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Dynamic db.Model classes ?
Have you looked at the class db.Expando. That has the ability to
create dynamic properties.
But it sounds like you want to have runtime determined kinds. In
this case, expando is not what you need. Take a look at
datastore.Entity, which is what underlies the Model classes, as it has
the precise interface you are indicating below.
Please be warned, however, that the Entity class is not documented
and you may not be able to get support for it. I might be able to
answer a couple of questions if that's the route you would like to
choose, but it's not officially supported.
On Sep 26, 4:19 pm, koblas <[EMAIL PROTECTED]> wrote:
> I'm not going to make any claims to being a python expert, nor is this
> a trivial question.
>
> What I want to do is have the ability to have an abstract interface
> for table contruction -- think UI where you can say "add field ...
> type String". Once you've specified the database table format from
> the UI, would like to take advatange of the non-tightly structured
> database underlying App Engine.
>
> What I would like to have is a class like:
> GenericTable(db.Model)
>
> def __init__(self, tbl) :
> ...
> def __getattr__(self, name) :
> for purposes of example...
>
> So in my view code I can say:
> tbl = GenericTable("books")
> items = tbl.all()
> for item in items :
> ...something interesting...
> ...with the ability to say item['price'] -- via the above
> __getattr__
>
> Hopefully this gives you a good idea of intent, where things are
> getting muddled up is I'm not sure if it's better to extend db.Model /
> db.PropertiedClass or build something totally new from the ground
> up...
>
> Anybody tried this before, or maybe has some good pointers on what is
> a "better" course of action?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: Only Once per user
What you would like to use is:
result = UserSetting.get_or_insert(key_name='user:%s' %
users.get_current_user(), owner users.get_current_user())
On Sep 26, 6:08 pm, fedekun <[EMAIL PROTECTED]> wrote:
> Hi, i want to save some settings for each user, and the way i'm doing it so
> far is
>
> title = self.request.get("title")
>
> result = UsersSettings.gql("WHERE owner=:1",
> users.get_current_user().nickname())
> if result.count() == 0:
> result = UsersSettings()
>
> result.title = title
> result.owner = users.get_current_user().nickname()
>
> db.put(result)
>
> What i want to do is create it if it doesnt exists or else modify it, but i
> cant figure out why it does not modify it, it creates it but i cannot modify
> it :(
> --
> Best Regards.
> fedekun
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Release of AppEngine 1.1.4 SDK
Hello, This evening we have released the AppEngine 1.1.4 SDK. It addresses some of the problems that Windows users have had with static files on dev_appserver. If you are working on Windows and an existing application started telling you something like the following message, this fix is for you: configuration file invalid: regex does not compile: bogus escape: '\\xa' You can download it from the project site here: http://code.google.com/p/googleappengine/downloads/list - Rafe Kaplan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Fixing Blob output for db.Model.to_xml()
Folks, Rafe Kaplan of the AppEngine team here. I'm going to fix a small issue that might effect applications that want to export Blob data as XML. It's been reported as issue 430, and you can read about it here: http://code.google.com/p/googleappengine/issues/detail?id=430 The output of the XML document being produced by the to_xml method is always a Unicode string. The problem arises when binary data is converted to unicode which doesn't encode properly. The solution that I am going to pursue is to convert all Blob objects to a text encoding format. I was thinking that base64 is a typical solution, but wanted to find out if anyone on the boards had opinions or ideas about how better to encode binary data in to an XML document. Also, this change will change the behavior of applications that already output Blob data to XML. Normally, we do not make changes to API's that can break already existing application, but given that this function is probably broken in most places it is being used, it seems appropriate. Hopefully, those applications will already treat text in such output as opaque binary data. I cannot promise that I will honor all ideas, but I want to hear as many as I can. I don't believe I've thought of everything! So, please respond to this thread with ideas and suggestions if this feature interests you. - Rafe Kaplan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Fixing Blob output for db.Model.to_xml()
Actually, that's an idea. Include a bit of additional info with the data. But maybe those bits of info should go in to attributes? On Sep 30, 11:58 am, Sylvain <[EMAIL PROTECTED]> wrote: > Cool :) > > I like the to_xml function, but it was broken with a model with a blob > > Print the same thing than the data viewer ? > Something like that : > > "4013 bytes, SHA-1 = 250d99ae712b26f50a26d2232c02ec3c3f05f789" > > Regards > > On 30 sep, 20:32, Rafe <[EMAIL PROTECTED]> wrote: > > > Folks, > > > Rafe Kaplan of the AppEngine team here. I'm going to fix a small > > issue that might effect applications that want to export Blob data as > > XML. It's been reported as issue 430, and you can read about it here: > > > http://code.google.com/p/googleappengine/issues/detail?id=430 > > > The output of the XML document being produced by the to_xml method > > is always a Unicode string. The problem arises when binary data is > > converted to unicode which doesn't encode properly. The solution that > > I am going to pursue is to convert all Blob objects to a text encoding > > format. I was thinking that base64 is a typical solution, but wanted > > to find out if anyone on the boards had opinions or ideas about how > > better to encode binary data in to an XML document. > > > Also, this change will change the behavior of applications that > > already output Blob data to XML. Normally, we do not make changes to > > API's that can break already existing application, but given that this > > function is probably broken in most places it is being used, it seems > > appropriate. Hopefully, those applications will already treat text in > > such output as opaque binary data. > > > I cannot promise that I will honor all ideas, but I want to hear as > > many as I can. I don't believe I've thought of everything! So, > > please respond to this thread with ideas and suggestions if this > > feature interests you. > > > - Rafe Kaplan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Fixing Blob output for db.Model.to_xml()
No it does not at this time. On Sep 30, 12:49 pm, Davide Rognoni <[EMAIL PROTECTED]> wrote: > Does "db.Model.from_xml(xmlstring)" exist? > > On Sep 30, 8:58 pm, Sylvain <[EMAIL PROTECTED]> wrote: > > > Cool :) > > > I like the to_xml function, but it was broken with a model with a blob > > > Print the same thing than the data viewer ? > > Something like that : > > > "4013 bytes, SHA-1 = 250d99ae712b26f50a26d2232c02ec3c3f05f789" > > > Regards > > > On 30 sep, 20:32, Rafe <[EMAIL PROTECTED]> wrote: > > > > Folks, > > > > Rafe Kaplan of the AppEngine team here. I'm going to fix a small > > > issue that might effect applications that want to export Blob data as > > > XML. It's been reported as issue 430, and you can read about it here: > > > > http://code.google.com/p/googleappengine/issues/detail?id=430 > > > > The output of the XML document being produced by the to_xml method > > > is always a Unicode string. The problem arises when binary data is > > > converted to unicode which doesn't encode properly. The solution that > > > I am going to pursue is to convert all Blob objects to a text encoding > > > format. I was thinking that base64 is a typical solution, but wanted > > > to find out if anyone on the boards had opinions or ideas about how > > > better to encode binary data in to an XML document. > > > > Also, this change will change the behavior of applications that > > > already output Blob data to XML. Normally, we do not make changes to > > > API's that can break already existing application, but given that this > > > function is probably broken in most places it is being used, it seems > > > appropriate. Hopefully, those applications will already treat text in > > > such output as opaque binary data. > > > > I cannot promise that I will honor all ideas, but I want to hear as > > > many as I can. I don't believe I've thought of everything! So, > > > please respond to this thread with ideas and suggestions if this > > > feature interests you. > > > > - Rafe Kaplan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: ReferenceProperty - id access without fetching the entity
Mazia is correct, there is no guarantee that this will work. In
fact, it is very likely it will not work in the future. We may in the
future implement lazy loading so that you can access the key directly
without loading the entity (a.C.key()) however, for now, this is
guaranteed to work:
A.C.get_value_for_datastore(a).key()
On Sep 29, 6:23 pm, Andy Freeman <[EMAIL PROTECTED]> wrote:
> Is there an approved way to copy a ReferenceProperty from one entity
> to another without fetching the referred to entity from the datastore?
>
> In other words,
>
> class C(db.Model):
> ...
>
> class A(db.Model):
> C = db.ReferenceProperty(reference_class=C)
>
> class B(db.Model):
> C = db.ReferenceProperty(reference_class=C)
>
> a = {some query}
> b = B()
> # I would like to do the next assignment without retrieving the
> relevant entity
> # from the data store.
> b.C = a.C
>
> Yes, I know that a._C.id() can be used to read the id, but that
> doesn't seem to be part of the documented interface.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: Using ReferenceProperty is very(!) slow
Waldemar,
It is not necessary to have a separate Property type for accessing a
model key without loading it from the datastore. You can instead:
class MyModel(db.Model):
my_reference = db.ReferenceProperty()
my_instance = MyModel.all().get()
MyModel.my_reference.get_value_for_datastore(my_instance)
On Sep 13, 4:36 am, Waldemar Kornewald <[EMAIL PROTECTED]> wrote:
> Hi Frank,
> I reordered your mail a little bit.
>
> On Sep 12, 9:26 pm, Frank <[EMAIL PROTECTED]> wrote:
>
> > And the most puzzling is that this is always the same 'oParent' 150
> > times, since I'm listing its children, so I would expect this
> >ReferencePropertyto be cached already.
>
> ReferencePropertyonly caches for a single model, but you have 150
> models, so every child will get() its parent.
>
> > of course I am not talking about accessing theReferenceProperty'sown
> > properties, I am only interested to see if it's None (and I tried with
> > both '==' and 'is'), and also getting its id
> > (self.oParent.key().id()), and doing one or the other gives the same
> > behavior.
>
> As soon as you access oParent it will result in a get().
> Unfortunately, you can't get the key of aReferencePropertywithout
> dereferencing it. Well, there is a hacky solution:
> if self._oParent is None:
> ...
> Note that most properties store their real value in
> "_", but Google might change this any time, so I
> wouldn't use it in an important app.
>
> Instead, I'd suggest you either store the str(key) in a StringProperty
> and manually get() it or you use our KeyReferenceProperty from
> appenginepatch's snippet library. If your parent node model is
> ParentNode you could define this:
>
> parent_key = db.StringProperty()
> parent = KeyReferenceProperty('parent_key', ParentNode,
> use_key_name=False)
>
> The "parent_key" property will store the str(key) of the parent while
> the "parent" property allows to access the parent directly (like
> withReferenceProperty). So, in order to test whether it's None you would
> write:
> if self.parent_key is None:
> ...
> If you want to access the parent model instance you can just write
> self.parent. This separation between key and model instance also makes
> writing transactional code that has to pass around key_names a little
> bit easier.
>
> You can rip out the source
> here:http://trac-hg.assembla.com/appenginepatch/browser/ragendja/dbutils.py
>
> Alternatively, if you use Django you can integrate it with
> appenginepatch and get the whole snippet
> library:http://code.google.com/p/app-engine-patch/
> But then I'd suggest you fetch the most recent source from the
> repository because that contains a few additions like support for
> setting the key via the KeyReferenceProperty (self.parent =
> some_parent_object).
>
> Bye,
> Waldemar Kornewald
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: ReferenceProperty - id access without fetching the entity
Correction on this post :(
A.C.get_value_for_datastore(a)
It is not necessary to call 'key()' because the object that gets
returns IS the key.
On Oct 2, 3:02 pm, Rafe <[EMAIL PROTECTED]> wrote:
> Mazia is correct, there is no guarantee that this will work. In
> fact, it is very likely it will not work in the future. We may in the
> future implement lazy loading so that you can access the key directly
> without loading the entity (a.C.key()) however, for now, this is
> guaranteed to work:
>
> A.C.get_value_for_datastore(a).key()
>
> On Sep 29, 6:23 pm, Andy Freeman <[EMAIL PROTECTED]> wrote:
>
> > Is there an approved way to copy aReferencePropertyfrom one entity
> > to another without fetching the referred to entity from the datastore?
>
> > In other words,
>
> > class C(db.Model):
> > ...
>
> > class A(db.Model):
> > C = db.ReferenceProperty(reference_class=C)
>
> > class B(db.Model):
> > C = db.ReferenceProperty(reference_class=C)
>
> > a = {some query}
> > b = B()
> > # I would like to do the next assignment without retrieving the
> > relevant entity
> > # from the data store.
> > b.C = a.C
>
> > Yes, I know that a._C.id() can be used to read the id, but that
> > doesn't seem to be part of the documented interface.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] How to get ReferenceProperty's key without causing a 'get'
Folks,
There have been a number of people asking on the forums what the
correct way to get the key of a ReferenceProperty without causing a
whole 'get' to the datastore. This can be especially inefficient if
you need to iterate over 100 or so values from a query, when all you
need is, say, the string version of all of those objects keys.
Let's look at an example:
class Post(db.Model):
title = db.StringProperty()
text = db.StringProperty(multiline=True)
class Comment(db.Model):
text = db.StringProperty()
post = db.ReferenceProperty(Post, collection_name='comments')
Let's say you wanted to generate a list of URLs from all the
comments in your system with links to the actual posts. This would be
an inefficient way to do this:
def generate_delete_urls(post):
urls = []
for comment in post:
key = comment.post.key()
urls.append('http://myapp.appspot.com/post/%s' % key)
The problem is that each time you de-reference the 'post' property,
it will cause a call to 'get' from the Datastore for information you
don't need.
Here is the correct way to get keys for all the posts:
def generate_delete_urls(post):
urls = []
for comment in post:
key = Comment.post.get_value_for_datastore(comment)
urls.append('http://myapp.appspot.com/post/%s' % key)
Right now, some folks may be using the protected variables that get
stored on the Model instance. This is not a good way to access
objects as it could well change in the future. If this happens, your
application can break!
So, to make sure it's clear, let me break it down for you:
reference_property = Comment.post # Gets actual
db.ReferenceProperty object
key = reference_property.get_value_for_datastore(instance)
- Rafe Kaplan
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: Incoming Mail Headers
Yes, there is a way to get the raw headers. In fact you can get the
whole raw email message and bypass the way the API presents it if you
like.
If you are using Python, the api provides you with a way. Email
message objects (for example appengine.api.mail.InboundEmailMessage)
has an attribute 'original'. This is a Python email.Message.Message:
http://docs.python.org/library/email.message.html
You can the access headers via:
my_message.original['header']
my_message.original.get('header')
my_message.original.get_all('header')
I presume you are talking about Python because in Java, the
javax.mail.internet.MimeMessage object that the API uses has methods
for accessessing headers as well.
http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeMessage.html
Was this the information you were looking for?
On Dec 20, 1:30 am, Jason wrote:
> From my reading of the documentation, there is no way to get the raw
> headers of an incoming mail message. Is this correct? Are there any
> announced plans for expanding this functionality to include raw
> headers, if so? My application requires uncommon message headers.
--
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-appeng...@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: Subclassing PolyModel
There is currently no proper way to do "re-root" a polymodel the way you are describing. However, there may be a solution for your particular problem. I don't know enough about your actual implementation however you might get away with simply doing a non- Model based mix-in. So, write your memcache utility class AS IF it inherits from PolyModel, but don't actually allow it to do so. Like this: class CoolFeature(object): def put(self): ... clear memcache ... super(CoolFeature, self).put() Now define your root class: class MyModel(CoolFeature, polymodel.PolyModel): ... Here comes the Python lesson, so forgive me if you already know all this ;) The key is that you use 'super' correctly and that you have CoolFeature be the first class your model class inherits from. 'super' allows you to traverse your objects functionality correctly according to the python "method resolution order". You can see this order by for any class by studying MyModel.__mro__. This indicates the order which calls to super will traverse your class definitions. If you do: class A(object): def p(self): print 'A' class B(object): def p(self): print 'B' super(B, self).p() class C(B, A): def p(self): print 'C' super(C, self).p() ...calling C().p() will print: C B A You should be able to implement whatever functionality you need this way. Let me know if there are issues with doing that. On Mar 3, 7:40 pm, Nickolas Daskalou wrote: > I should state that I can set the entity kind that's saved in the > Datastore by adding a kind() method on my "real" models, however the > class list property of the saved entities still includes the "special" > PolyModel subclass in it, and I'm not sure if that's a bad thing or > not. > > On Mar 4, 2:16 pm, Nickolas Daskalou wrote: > > > I've been trying to create a "special" subclass of PolyModel (that does cool > > stuff like update Memcache after an entity put()) which my polymodel models > > can inherit from (instead of inheriting from db.polymodel.PolyModel). > > > This has the nasty side effect though of making that "special" subclass of > > PolyModel the root class for my polymodel models. > > > Is there a way around this? > > > Eg. Telling db.polymodel.PolyModel to NOT include the first direct subclass > > in the class hierarchy that is saved to the Datastore? Or writing my own > > PolyModel by basically copying db.polymodel and changing code where > > appropriate? > > > Appreciate any help. > > > Nick -- 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-appeng...@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: Subclassing PolyModel
The built-in property classes are not likely to change in future releases. I've already written an article about extending properties and am loath to break peoples existing applications (even though it sometimes happens by mistake - and we then revert those changes): http://code.google.com/appengine/articles/extending_models.html Nice analysis PK. As described, the main problem with your first approach was that properties are not initialized unless they use the Propertied base class. The problem with the Propertied base class is that it is too tied to the actual Datastore implementation. Ideally, there would be a less specific meta-class that simply does property initialization which can be used by other class that do not inherit from models but want to be mixins. This would be ideal: class CoolFeature(db.ModelMixin): my_prop = db.StringProperty() class IUseCoolFeature(CoolFeature, db.Model): ... Or what if you wanted to use it with an Expando? class IUseCoolFeature(CoolFeature, db.Expando): ... Learned quite a bit since releasing db.py. Expando should have been written as a mixin in the first place. On Mar 5, 1:31 am, Nickolas Daskalou wrote: > c...@your solution, PK! > > Since db.PropertiedClass is not documented in the official docs, I'm > assuming there's a chance that its implemented could change in future > releases, and possibly break your code yeah? > > Can someone from Google please comment on whether db.PropertiedClass is > "concrete" enough to be able to use it in such a manner as described in PK's > article? > > Nick > > On 5 March 2010 20:18, Nickolas Daskalou wrote: > > > > > Thanks PK, I'll check it out now. > > > Nick > > > On 5 March 2010 19:41, PK wrote: > > >> Hi Nick, > > >> I have been using the pattern described by Rafe very successfully in > >> my app. Regarding the problem you are desribing I have written up how > >> I solved the problem here: > > >>http://www.gae123.com/articles/tds/model-mixin.html > > >> Read the whole page for the details or just scroll to the bottom for > >> the solution that has worked for me. > > >> PK > >>http://www.gae123.com > > >> On Mar 4, 10:22 pm, Nickolas Daskalou wrote: > >> > Using non-Model mix-ins worked a treat. Thanks again Rafe. > > >> > There is one small problem I'm hoping you can help me with (again). It's > >> not > >> > a show-stopper because I can work around it, however I'm hoping you'd > >> know > >> > of a nicer way to do this. Note that it's not only specific to > >> PolyModel, > >> > but to db.Model as well. > > >> > The problem is with adding extra db.* properties to these mix-ins (so > >> that > >> > all subclasses that use the mix-in get these extra properties stored in > >> the > >> > Datastore). > > >> > Let's say I change the CoolFeature mix-in to this: > > >> > class CoolFeature(object): > > >> > * cool_name = db.StringProperty()* > > >> > def put(self): > >> > self.cool_name = 'Cool ' + self.name > >> > super(CoolFeature, self).put() > > >> > class MyModel(CoolFeature,db.Model): > > >> > name = db.StringProperty() > > >> > If I then create an instance of MyModel and try put()'ing it to the > >> > Datastore: > > >> > mm = MyModel(name='blah') > >> > mm.put() > > >> > I get this error: > > >> > Traceback (most recent call last): > >> > ... > >> > File > > >> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngi > >> > >> ne-default.bundle/Contents/Resources/google_appengine/google/appengine/ext > >> /db/__init__.py", > >> > line 473, in __set__ > >> > setattr(model_instance, self._attr_name(), value) > >> > File > > >> "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngi > >> > >> ne-default.bundle/Contents/Resources/google_appengine/google/appengine/ext > >> /db/__init__.py", > >> > line 588, in _attr_name > >> > return '_' + self.name > >> > TypeError: cannot concatenate 'str' and 'NoneType' objects > > >> > This error occurs both on the dev and production servers. > > >> > Upon further investigation, the error occurs because the name property > &
[google-appengine] Re: Did the API for Model._toPb change recently?
Has your modified version of SearchableModel overloaded
Query._ToPb. You will need to update your application so that it can
accept the additional parameter. As a catch all, you might like to
have the signature end in *params, **kwds and pass those along to the
superclass version of _ToPb. This will make sure it is compatible
with signature changes.
Sorry for the disruption!
On Aug 6, 5:49 pm, Mahmoud wrote:
> The search functionality in our app mysteriously started breaking
> today. We use a modified version of SearcheableModel. Here is the
> stack trace:
>
> results = SpontyUser.all().search(query).order('name').fetch
> (PAGE_SIZE+1)
> File "/base/python_lib/versions/1/google/appengine/ext/db/
> __init__.py", line 1455, in fetch
> raw = self._get_query().Get(limit, offset)
> File "/base/python_lib/versions/1/google/appengine/api/
> datastore.py", line 981, in Get
> prefetch_count=limit)._Get(limit)
> File "/base/python_lib/versions/1/google/appengine/api/
> datastore.py", line 917, in _Run
> pb = self._ToPb(limit, offset, prefetch_count)
> TypeError: _ToPb() takes at most 3 arguments (4 given)
>
> Did the SDK/API change today? did anyone see else see this?
--~--~-~--~~~---~--~~
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: GAE production error at this moment? : Class-key is a derived property and cannot be set.
It looks like you are trying to set a 'class' attribute on a PolyModel instance. Have you been doing anything like this (maybe created your own 'class' property) or is this something that started happening with the new API release? On Oct 12, 3:18 pm, Alan Xing wrote: > E 10-12 03:02PM 22.599 Class-key is a derived property and cannot be set. --~--~-~--~~~---~--~~ 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] Change in parameters to Model.__init__ may cause errors when overridden.
Because of our new software release, there are a few applications that might be experiencing problems where they have overridden Model.__init__ or any of its sub-classes. The problem is most likely because of the way these sub-classes have been handing the _app and _from_entity parameters. The App Engine team is already in the process of fixing this so that existing applications that have this problem will be automatically fixed. For those who are interested in fixing their applications right away, please allow me to explain what the problem most likely is and what you can do to fix it. The advice I am going to provide is applicable to all code and is how it was intended to be used (we recognize that developers will not always use things as intended, and we endeavor to respect that;). All function and constructor parameters that begin with '_' are meant to be "protected" and undocumented. They are not meant to be used or referred to be application developers. We use them when one part of the API needs to communicate information with another part but we don't want it to be considered part of the actual API. Specifically, the Model.__init__ method has the parameters _app and _from_entity that must be correctly set by any Model sub-class to function properly. Here is the SDK 1.2.5 signature including the protected parameters: def __init__( self, parent=None, key_name=None, _app=None, _from_entity=False, **kwds): ... A program that is having problem with the 1.2.6 version of the Model class might have defined a Model sub-class as: class MyModel(db.Model): def __init__( self, parent=None, key_name=None, _app=None, _from_entity=False, **kwds): ... Do important stuff ... super(MyModel, self).__init__( parent, key_name, _app, _from_entity, **kwds) The problem this application will encounter is that a new positional parameter 'key' was inserted between key_name and _app because we (mistakenly) believed that these protected attributes would not be used. This means that when instantiating MyModel instances, particularly during the Datastore 'get' process, MyModel is assigning the '_app' value to the 'key' attribute, assigning '_from_entity' to '_app' and overriding '_from_entity' with its default value 'False'. In Python, positional parameters and keyword parameters can be used fairly interchangeably. If a key-word parameter dictionary is passed where a positional is expected, the value in the dictionary will be assigned to the correct positional parameter. The better way to have written the MyModel constructor would have been: class MyModel(db.Model): def __init__( self, parent=None, key_name=None, **kwds): ... Do important stuff ... super(MyModel, self).__init__( parent, key_name, **kwds) One can just leave out all references to all protected parameters and rely on them being transmitted via 'kwds'. Again, the App Engine team apologize for the inconvenience this has caused and we are working to remedy it as soon as possible. - Rafe Kaplan --~--~-~--~~~---~--~~ 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: GAE production error at this moment? : Class-key is a derived property and cannot be set.
Alan, I think we might have determined what was causing the problem with your application. I think you are having this problem because you overrode the __init__ method of your PolyModel in a way that we were not expecting. Please see this thread: http://groups.google.com/group/google-appengine/browse_thread/thread/c67228d9a1fc6859 We are working to fix the problem, but if you please, could you check to see if this is what is causing the problem for your application? Here's how it's related to PolyModel. If you have attempted to copy _app and _from_entity as positional parameters through your overridden constructor, you would have been one positional parameter short. This parameter is '_from_entity' which is used to tell the Model constructor that it is loading from the datastore and can ignore errors that occur when assigning to derived (read-only) properties. Thanks for bringing this issue to our attention. Let me know if there is anything else I can do to help. - Rafe Kaplan On Oct 13, 1:19 am, Alan Xing wrote: > We nailed down the problem to a third party package called 'appenginepatch' > we use. This 'appenginepatch' seems not compatible with some GAE backend > updates deployed on yesterday(Monday) afternoon. > If any one of you has good patch solution on 'appenginepatch', could you > please help share? > > Note: We actually resolved the 'Class-key is a derived property and cannot > be set.' problem by some hack. But there are more problems with > 'appenginepatch' after that. > > Thanks, > Alan > > > > On Mon, Oct 12, 2009 at 11:15 PM, Alan Xing wrote: > > It is very clear this problem is with GAE poly model. All my > > functionalities that touch any poly model objects are breaking. Anything > > that don't touch is working fine. > > We have been using poly model since day one. We haven't changed any poly > > model class for a few weeks. We never had this problem before. --~--~-~--~~~---~--~~ 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] Avoid using 'key' parameter to Model constructor as a positional parameter.
With the release of the 1.2.6 SDK, it is now possible to specify a key
directly to a newly constructed model instance. To make this possible
we added 'key' as a positional parameter to the Model constructor.
Doing so was a mistake as it caused certain applications to break in a
relatively subtle way. To remedy the situation we will release an
updated version of the SDK to change the signature of the Model
constructor back to one that is compatible with older source code. We
will do this by change 'key' to a key-word only parameter.
There is a chance that applications that have started to make use of
the 'key' parameter as a positional parameter will break when we make
this change, which we regret, but it is a worse outcome, we believe,
if older applications that might have been running well for ages were
to suddenly stop working. If you are using the 'key' parameter with
the 1.2.6 SDK, it is easy to make sure any code you write is
compatible with our upcoming patch. The solution is to always specify
the 'key' parameter using a keyword, like so:
# Old code:
instance = MyModel(my_parent, None, db.Key.from_path('MyModel', 'my-
name'))
# New code:
instance = MyModel(my_parent, key=db.Key.from_path('MyModel', 'my-
name'))
As you can see, the key parameter is now assigned using 'key='.
Again, we apologize for the confusion and will remedy the situation as
soon as we can.
- Rafe Kaplan
App Engine Team
--~--~-~--~~~---~--~~
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: Incoming Mail Attachments
The content is in fact an instance of EncodedPayload. You can decode the content by calling 'decode' on the EncodedPayload object. Hope that this is what you were looking for. - Rafe Kaplan On Oct 19, 10:07 am, Joshua Smith wrote: > The attachments property on incoming mail is a list of pairs: name, > contents > > (note that the docs say "attachments is a list of element pairs > containing file types and contents." which is not correct) > > The contents are still encoded. For example: > > From nobody Mon Oct 19 15:47:38 2009 > content-transfer-encoding: base64 > > iVBORw0KGgoNSUhEUgAAAaUAAAEUCAIEJr4pAAAXrGlDQ1BJQ0MgUHJvZmlsZQAAeAH t > ... > > Do I need to write something to parse this and deal with the different > possible values of content-transfer-encoding? Or is there a built-in > or an appengine API that will do that for me? > > Also, when there are references to these attachments within the HTML, > such as > > it appears that there is no way to know what the mapping is between > the cid's and the attachments. > > This makes it impossible for me to display the email in a browser with > the images in-line. > > -Joshua --~--~-~--~~~---~--~~ 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: How does The Python datastore select the class for an entity (or: swapping classes through the datastore)?
So, what's happening here is that when a class gets registered there
is a mapping from kind to class just as Nick said. This mapping will
be the last class that you created with that unqualified name. In
this case, your last mapping is y.A. From that point on, every time
you load an entity from datastore of kind A, it will create an
instance of y.A even if it was originally created as x.A.
App Engine deliberately doe not try to prevent developers from
defining more than one class with the same name more than once.
Developers need to be careful about keeping that space unambiguous.
You can use the kind method to store fully qualified instance names
which will allow you to use classes with the same name in different
modules.
On Oct 21, 11:43 pm, Tonny wrote:
> Thank you or the reply. This is great news - if I understood it
> correctly it means moving model classes to new modules is possible
> (redesign/cleanups).
>
> What i don't understand is how GAE searches for the actual class,
> given that it only has an unqualified name. Does it iterate all
> modules in the app or something else?
>
> Cheers
> Tonny
>
> On 21 Okt., 16:37, "Nick Johnson (Google)"
> wrote:
>
>
>
> > Hi Tonny,
> > The SDK maintains a mapping between kind name and class. The kind name is
> > determined by calling kind() on your class, and defaults to the
> > (unqualified) name of the class. Because you have two classes with the same
> > name in different modules, they both have the same kind name.
>
> > The solution is to override kind() on one or both classes:
>
> > class MyModel(db.Model):
> > @classmethod
> > def kind(self):
> > return 'some_other_value'
>
> > -Nick Johnson
>
> > On Wed, Oct 21, 2009 at 11:00 AM, Tonny wrote:
>
> > > I ran into a fuzzy little thing today. I have to classes with the same
> > > name in different modules and both inherits from the Model class
> > > (let's call them x.A and y.A). I've created an instance of x.A (let's
> > > call it a1) and put it to the datastore, i then referenced the
> > > instance from an a.B entity (let's say b1). Now later fetching b1 and
> > > accessing the a1 through the reference property on b1 i get an object
> > > of the class y.A. How did this happen?
>
> > > Maybe i should put this to code:
>
> > > module x
> > > class A(db.Model):
> > > name = db.StringProperty()
> > > class B(db.Model):
> > > name = db.StringProperty
> > > other = db.ReferenceProperty(reference_class=A)
>
> > > module y
> > > class A(db.Model):
> > > name = db.StringProperty()
>
> > > # now let's create som entities
> > > a1 = x.A(name='Test')
> > > a1.put()
> > > b1 = x.B(name = 'Some Name', other=a1)
> > > b1.put()
> > > b2 = x.B.all().filter('name =', 'Some Name').get()
> > > a2 = b2.other # now this will be an instance of y.A, even though we've
> > > created no such instance or worked with module y in module a or the
> > > end code snippet.
>
> > > Magic, a bug, a feature?
>
> > > Regards
> > > Tonny
>
> > --
> > 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: How does The Python datastore select the class for an entity (or: swapping classes through the datastore)?
Yes, you can rename the kind of a class. Just make sure that any non-class bound GQL you have written are adjusted. In other words, where you have used db.gql vs. db.Model.gql. On Oct 22, 10:52 am, gae123 wrote: > NickandRafe, > > this is great to know. Am I correct to assume that this gives us an > easy way to rename classes? Let's say I had this: > > class Foo(db.Model): > > > and want to rename it to Bar in my code but I have an app already > running with lots of data. I can just say: > > class Bar(db.Model): > �...@classmethod > def kind(cls): > return 'Foo' > > ... > > 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: 'module' object has no attribute 'Message'
Mike,
I was not able to duplicate the problem you are describing. I
pasted your code directly in to a mail handling file on my test-app
and sent it an email. In my logs it says 'It worked'.
From the stack trace it looks like it's something that's running on
the production system. Is it possible another part of your
application might have changed any of the email modules?
On Oct 22, 12:22 pm, Mike P wrote:
> using this code
>
> import logging
> from google.appengine.api import mail
> from google.appengine.ext import webapp
> from google.appengine.ext.webapp.util import run_wsgi_app
> from google.appengine.ext.webapp import mail_handlers
>
> class MailHandler(mail_handlers.InboundMailHandler):
> def receive(self, message):
> logging.debug("it worked")
>
> application = webapp.WSGIApplication([('/.*', MailHandler)],
> debug=True)
> def main():
> logging.getLogger().setLevel(logging.DEBUG)
> run_wsgi_app(application)
> if __name__ == "__main__":
> main()
>
> I get this error
>
> 'module' object has no attribute 'Message'
> Traceback (most recent call last):
> File "/base/python_lib/versions/1/google/appengine/ext/webapp/
> __init__.py", line 509, in __call__
> handler.post(*groups)
> File "/base/python_lib/versions/1/google/appengine/ext/webapp/
> mail_handlers.py", line 58, in post
> self.receive(mail.InboundEmailMessage(self.request.body))
> File "/base/python_lib/versions/1/google/appengine/api/mail.py",
> line 525, in __init__
> mime_message = _parse_mime_message(mime_message)
> File "/base/python_lib/versions/1/google/appengine/api/mail.py",
> line 206, in _parse_mime_message
> if isinstance(mime_message, email.Message.Message):
> AttributeError: 'module' object has no attribute 'Message'
>
> Can anybody help?
--~--~-~--~~~---~--~~
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: db transaction: "Cannot operate on different entity groups in a transaction"?
It looks like you are trying to make a the parent of b. You are doing it like this: B(a=a) I think you meant: B(parent=a) P.S. Unrelated, I would like to point out that by calling A.get outside of the transaction function you could end up losing transactional integrity. The values for a.up and a.down could change in the datastore between A.get and the transaction function. On Oct 24, 4:16 am, log1 wrote: > Hello, > > This is my problem: > > class A(db.Model): > up = db.IntegerProperty(default=0, required=True) > down = db.IntegerProperty(default=0, required=True) > > def move(self, direction): > a = A.get(self.key()) > > def txn(a, direction): > if direction == "up": > a.up += 1 > else: > a.down += 1 > a.put() # OK > b = B(a=a) > b.put() # Cannot operate on different entity groups in a > transaction??? > > db.run_in_transaction(txn, a, direction) > > class B(db.Model): > a = db.ReferenceProperty(A, collection_name='a_b') > > Can somebody tell me what I'm doing wrong? > 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: db transaction: "Cannot operate on different entity groups in a transaction"?
Oh, I also realize you are meaning to set the 'a' property on B, which is usually good modelling practice. So, you need to do: b = B(parent=a, a=a) On Oct 24, 4:16 am, log1 wrote: > Hello, > > This is my problem: > > class A(db.Model): > up = db.IntegerProperty(default=0, required=True) > down = db.IntegerProperty(default=0, required=True) > > def move(self, direction): > a = A.get(self.key()) > > def txn(a, direction): > if direction == "up": > a.up += 1 > else: > a.down += 1 > a.put() # OK > b = B(a=a) > b.put() # Cannot operate on different entity groups in a > transaction??? > > db.run_in_transaction(txn, a, direction) > > class B(db.Model): > a = db.ReferenceProperty(A, collection_name='a_b') > > Can somebody tell me what I'm doing wrong? > 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: Possible saving of metadata space by having short model class name?
And alternative would be to override 'kind'. Just make sure you remember when doing GQL queries in the console: class MyModelClassWithLongName(db.Model): def kind(self): return 'MWLN' On Nov 4, 6:55 am, Anh Hai Trinh wrote: > Since every full entity key includes the name of its model class (and > its parents'), is the following scheme preferable in term of metadata > space usage? > > Instead of > > class MyModelClassWithLongName(db.Model): > ... > > I'd use: > > class MWLN(db.Model): > ... > > MyModelWithLongName = MWLN > > aht --~--~-~--~~~---~--~~ 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: Google App Engine for a huge website
Felix, The timing of your question is excellent. Last night we just released App Engine 1.3.0 which adds the BlobStore API. This new API supports file upload and download up to 50MB. http://googleappengine.blogspot.com/2009/12/app-engine-sdk-130-released-including.html At least that's an answer for the file size limitation part of your question. - Rafe Kaplan On Dec 14, 11:57 am, Felix wrote: > Hi, I am thinking about using Google App Engine.It is going to be a > huge website. In that case, what is your piece of advice about using > Google App Engine. I heard GAE has restrictions like we cannot store > images or files more than 1MB limit(they are going to change this from > what I read in the GAE roadmap),query is limited to 1000 results, and > I am also going to se web2py with GAE. So I would like to know your > comments. > > 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-appeng...@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: newbie problems with TextProperty. Pls help
Are you copying the text from your source code precisely in to your
post? If so, it looks like your definition of "content" is missing
parenthesis at the end of the definition. You have:
content = db.TextProperty
it should be:
content = db.TextProperty()
Your first attempt didn't work because it was required. You can
still make it required like you had before but you need to do the
assignment in the constructor:
so...
class myFeedDB(db.Model):
url = db.StringProperty(multiline=False)
content = db.TextProperty(required=True)
date = db.DateTimeProperty(auto_now=True)
newFeed = myFeedDB(content=db.Text("Hello everyone"))
newFeed.url = url
newFeed.put()
On Dec 16, 9:25 pm, observer247 wrote:
> I am not able to use the TextProperty field after I fetch it from the
> db. Also how do I view the complete structure of the db entry in the
> data Viewer. I somehow see only the indices.
>
> This is my db:
>
> class myFeedDB(db.Model):
> url = db.StringProperty(multiline=False)
> content = db.TextProperty
> date = db.DateTimeProperty(auto_now=True)
>
> And this is where I am adding an entry
>
> newFeed = myFeedDB()
> newFeed.url = url
> newFeed.content = db.Text("Hello everyone ")
> newFeed.put()
>
> But after fetching, I am not able to convert the textProperty ie
> content to a string. Please help me in either printing this or
> converting to a string.
>
> This is what I get:
>
> TEXT is
> For some reason, I just cannot store the content (of type
> TextProperty). If in the model I set it to required, my put is
> failing.
--~--~-~--~~~---~--~~
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: I want more fields than in DB models?
If you want to have a persistent class that you can add arbitrary vales to, try db.Expando. It will let you do: class Event(db.Model) : owner = db.UserProperty() title = db.StringProperty() content = db.StringProperty(multiline = True) e = Event() e.color = "Green" Color will then be stored along with the static properties owner, title and content. You check the presence or absence of those "dynamic" properties (the ones that are not defined in the class) like: hasattr(e, 'color') However, you could have also declared color and status as normal string properties and just left them unassigned. They would get put in the datastore as None. On Mar 3, 8:32 pm, disorderdev wrote: > Hi, I'm a newbie here, both python and app engine. a few questions: > I store some fields in DB, but when show message on Web, I need more > fields, most of them are calculated according to fields in DB, For now > I don't want to do the calculating on web, but when I add some fields > to the DB model class, the web dose not recognize them, all values are > None, what should I do? > > For example, I have a class > class Event(db.Model) : > owner = db.UserProperty() > title = db.StringProperty() > content = db.StringProperty(multiline = True) > status = None > color = None > > when showing events on web, I want 'color' and 'status', so after > retrieve the data from DB, I do the following: > > for event in events : > logger.info(event.status) > logger.info(event.color); > event.create_time = datetime.now() > event.status = "Finished" > event.color = "green" > > but on web, they are still None. > > BTW: I have to add status and color in class, or these fields are not > recognized. --~--~-~--~~~---~--~~ 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: Possible to send email from a different user?
If the user logs in to your application using their Google account, they should be able to send email as themselves. However, if your application does not require login, you should be able to send using an administrators email (so you can set one up for 'no-reply' and you should be able to set reply_to on that email. Does this help answer your question? - Rafe On Mar 4, 1:02 am, Noel wrote: > I'm trying to use Google App Engine as the server for an iPhone app. > The user can post some data, and I'd like the server to send an email > to another person on behalf of the user. For that, I need to be able > to set the sender's email address, but right now I get > InvalidSenderError. > > Is there some way around that? I don't mind if somewhere it shows that > it came from my domain, but I'd like to make it feel as much as > possible as if it came from the user (and it should be in the reply-to > field too). > > 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: PolyModel needs to be rethought
Rein, Thanks for taking the time to think about this stuff. It's important to think about alternatives to any design offered by the App Engine team, even if it means it leads to merely clearing up some misunderstandings about the underlying implementation. I think Andy's response sums up anything I was going to say and is correct. Properties that don't exist on leaf classes are not stored whatsoever in the datastore and are also not loaded when returned by a get or query fetch. One thing to realize about the difference between Datastore and the Datastore Model API that sits on top of it is that Datastore does not actually understand or care about the structure of the data that it stores in each Kind (what you refer to as "Table"). In fact, in order to make the model API behave more like the actual underlying Datastore implementation, we had to add a modified subclass of Model similar to PolyModel. If you have not had a chance, take a look at Expando. http://code.google.com/appengine/docs/python/datastore/expandoclass.html Notice how each instance of an Expando kind can have a unique "schema" when compared with all other instances. You can have: instance1.prop1 = 'a string' instance2.prop2 = 'a different property' instance3.prop1 = 1024 instance2 does not have prop1, while instance3 has a different type for prop1. It seems like under the hood Datastore acts more like a dict than a traditional object. Turns out not to be so far from the truth. If you look further you will see that the datastore.Entity class, which is where db.Model reads and writes info from the datastore, actually inherits from dict. This is all ok. It turns out that Datastore handles these cases very well. I'm guessing you might be more experienced with how SQL based object relational mapping algorithms work, such as Java's Hibernate. Hibernate allows you to map different class structures to either single tables (much like how PolyModel does it) and multiple tables as you have described. This makes good sense in an environment like SQL where joins are permitted. That's not to say that there will never be a case in App Engine where someone would benefit more from a polymorphic model based on multiple Kinds rather than a single kind. Most of those cases can be handled relatively well using db.ReferenceProperty. But an easier to use and more intuitive Python class that encapsulates this concept might be neat. You should see PolyModel as a reference implementation of a polymorphic class, but is not necessarily definitive. Everyone has different needs and the hope is that variations like Expando and PolyModel give people good starting points to build the best possible systems. Hope this is useful. - Rafe Kaplan On Mar 28, 9:43 am, Andy Freeman wrote: > > The problem with this is that if you have an inheritance > > hierarchy in which your outermost descendant(s) extend several fields, > > you've loaded your base entities with a mass of irrelevant fields > > containing an unusual (i've never seen that before). > > I'm pretty sure that the base entities (the things in the datastore) > don't have those fields. > > The "missing" message comes from a tool that is looking at instances > pulled from the datastore. It expects to see things and when it > doesn't, it says . > > > if you are building an application that, say for example, reads the > > fields (columns?) in the entity for display to the user (like the > > Dashboard's Data Viewer), you end up presenting irrelevant fields. > > That happens only if your application doesn't understand polymodels. > I'm still working through the details because "not polymodels" don't > support class_name() and polymodels don't support anything like > db.class_for_kind(). However, properties() appears to do the right > thing. > > One good reason for implementing Polymodels with a single entity type > is that implementing them with multiple entity types would make > queries a lot more expensive. > > If polymodels were implemented with multiple entity types, each > application-level query would need to make multiple datastore queries, > one for each applicable datastore entity type. If those queries are > done in the datastore (as with "in" queries), the datastore needs to > know some things that it doesn't currently know and the "30 datastore > queries per application query" limit comes into play. If those > queries are done in the application run time, limits (and maybe > transactions) will behave differently. > > I think that __key__ can be made to work across multiple entity types, > but wouldn't be surprised if implementing PolyModel with multiple &
[google-appengine] Re: Started to get 500 errors yesterday
this problem was caused when ProtoRPC was deployed as part of the App Engine runtime. The quickest solution for you is to make a small hack that will allow to continue to use your original version: http://groups.google.com/group/google-protorpc-discuss/browse_thread/thread/d7e3749420168a5b However, the main problem is that a few weeks ago, service_handlers were moved in to the protorpc.webapp module. What you need to do in this case is change your service_handler import from: from protorpc import service_handlers to from protorpc.webapp import service_handlers. I would recommend that fix your imports and use the latest version of ProtoRPC rather than relying on older versions. On Jun 16, 8:19 am, Rodrigo Pinho Pereira De Souza wrote: > Please, someone from Google take a look on this. > > I have an app, which uses google protorpc ( bookcalc.appspot.com ) > > This app was working fine until yesterday, but around 10pm( est > time ), it stopped working. > > The logs say: > exceptions.ImportError: Can not import service_handlers > > The code is: > from protorpc import service_handlers > > The protorpc is just a folder inside my application, so I assume that > this folder was removed someway. > > I will redeploy my application, and if this solves the problem, it > will indicate that there is a serious problem with GAE. > > Thanks, > Rodrigo Pinho Pereira de Souza -- 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] Google ProtoRPC library for writing simple web-services
Hi, Rafe Kaplan from the Google App Engine team here. I'd like to let
everyone know that we are soon to release a new tool called ProtoRPC
that will allow developers to easily build simple web services and
deploy them to their App Engine applications. ProtoRPC is designed to
be easy to get started and powerful enough to grow.
For the time being, ProtoRPC is only available on Python. If you are
familiar with writing App Engine DB models and webapp handlers,
specifying ProtoRPC services should be seem familiar to you. For
example here is a simple service:
class HelloRequest(messages.Message):
my_name = messages.StringField(1, required=True)
class HelloResponse(messages.Message):
hello = messages.StringField(1, required=True)
class HelloService(remote.Service):
@remote.method(HelloRequest, HelloResponse)
def hello(self, request):
return HelloResponse(
hello='Hello there, %s!' %
request.my_name)
Here we've defined a single service called HelloService that has a
single remote method called hello. Remote methods receive messages as
their requests and send messages as their responses. Defining a
message is very similar to defining a db.Model class. Defining a
service is very similar to defining a webapp.RequestHandler class and
is similarly mapped to URL paths within your webapp.
Here's one way to hook up to the HelloService using JQuery:
$.ajax({url: ‘/hello.hello’,
type: 'POST',
contentType: 'application/json',
data: ‘{ my_name: Bob }’,
dataType: 'json',
success: function(response) {
// The response is { hello: “Hello there, Bob!” }
alert(response.hello);
}
});
To learn more about ProtoRPC please visit the open source project
website and check out the getting started guide. You should consider
this library to be experimental, however we do plan to include it in
the App Engine Python SDK soon. It would be really great to hear some
early feedback from developers about their experience so that we can
make it better.
Project site: http://code.google.com/p/google-protorpc/
Getting started guide: http://goo.gl/NgcbD
--
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: Google ProtoRPC library for writing simple web-services
The short version is, yes, we would like to write a Java version. A more complicated answer is that it's not clear to me what kind of implementation it should be. The Python version of ProtoRPC was written such that it was possible to write services without a compilation step as the normal protocol buffer library requires: http://code.google.com/p/protobuf/ It's not clear to me if Java developers would want similar implementation to Python which does not require additional build steps or would they be ok just using the standard protocol buffer compiler. Ultimately having some kind of annotation driven way to define services and messages might be a good idea. I'd like to hear feedback from Java developers about it once they've had a look at the Python implementation. > Hi Rafe, > > That's great! Any planning for Java? > > Regards, > KhanhDM. -- 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: Google ProtoRPC library for writing simple web-services
Stephen,
First of all, thanks for taking the time to look at ProtoRPC. I
appreciate any and all feedback I can get.
ProtoRPC is actually a somewhat simplified version of Googles
protobufs. An important thing to remember about Protocol buffers is
that they are meant to be used in multiple contexts, for example using
streaming sockets. Since ProtoRPC is compatible with protocol
buffers, it is intended to be used to make writing services in those
contexts easier as well.
REST is something that is specific to HTTP. It has a much more
complex URL and message mapping structure on top of the need to
specify content structure. It's also intended to be resource based,
which I've always liked, but not every service is going to deal
directly with resources.
Might be neat to have a way to map REST-space to RPC methods. That
way you might get the best of both.
On Mar 18, 8:17 am, Stephen wrote:
> On Thu, Mar 17, 2011 at 9:48 PM, Rafe Kaplan wrote:
>
> > class HelloRequest(messages.Message):
> > my_name = messages.StringField(1, required=True)
>
> > class HelloResponse(messages.Message):
> > hello = messages.StringField(1, required=True)
>
> > class HelloService(remote.Service):
>
> > @remote.method(HelloRequest, HelloResponse)
> > def hello(self, request):
> > return HelloResponse(
> > hello='Hello there, %s!' %
> > request.my_name)
>
> > $.ajax({url: ‘/hello.hello’,
> > type: 'POST',
> > contentType: 'application/json',
> > data: ‘{ my_name: Bob }’,
> > dataType: 'json',
> > success: function(response) {
> > // The response is { hello: “Hello there, Bob!” }
> > alert(response.hello);
> > }
> > });
>
> Why expose an RPC style interface rather than REST style?
--
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.
