Re: [google-appengine] Re: Google Checkout
Yes, I also applied for the beta program immediately seeing the link. Thanks BaTien On Sat, Mar 5, 2011 at 11:14 PM, Jeff Schnitzer j...@infohazard.org wrote: Wow, thanks for that link! This explains why Google Checkout seems like abandonware - they're about to roll out a whole new system. I've applied for the beta program. Jeff On Sat, Mar 5, 2011 at 11:38 AM, Kaan Soral kaanso...@gmail.com wrote: Google bought Social Gold, Social Gold was the greatest payment system ever, even other payment providers used them, although they could implement credit card processing and Paypal themselves I hope Google In-App Payments keep the simplicity and excellence. http://checkout.google.com/support/sell/bin/request.py?contact_type=inapp_payment I have spent a lot of time reading Paypal services, each service was missing something for me. Some of them didn't accept credit cards directly, some of them didn't support subscriptions, some of them are only available to US/Canada companies etc. I have filled the form more than a week ago, I also have a very big application to show off but I didn't received any reply yet. On Mar 5, 9:21 am, anton savchuk anton.antoh...@gmail.com wrote: Yes, more likely PayPal will be decision.. He really does work.. -- 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. -- 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. -- Dr. Duong BaTien DBGROUPS BudhNet -- 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.
Re: [google-appengine] Re: Google Checkout
Hi Jeff: I will soon have to deal with this issue. It would be nice if you can document your lesion learned, especially the best practice in regard to local persistence with Ocjectify. Thanks for your effort and recently released objectify-3.0x Duong BaTien DBGROUPS and BudhNet On Fri, Mar 4, 2011 at 5:44 PM, Jeff Schnitzer j...@infohazard.org wrote: I'm about 80% through with both Google Checkout and Paypal integration for a pure-digital service. I must say, Google Checkout is VERY disappointing - it seems to be an abandoned product. * The Java SDK doesn't even compile. * The binaries don't run on GAE (jaxb issues). * The documentation is not very helpful. Basically you have to do your own XML processing. The fact that the server must submit to a valid HTTPS callback makes testing a pain in the ass - this requirement exists even for the sandbox. I had to proxy through appengine *and* a cloud host ssh tunnel just to get the @#$%! payload to my Eclipse dev system. Overall the whole experience feels janky and utterly fails to inspire trust. Say what you will about Paypal's evil eye and their confusing product line, at least the integration is going fairly smoothly. It feels like 1990s technology but it works. The most helpful advice I can offer: Forget everything else on their stupid overmarketed website and go straight for Web Payments Standard. Tirade over. Jeff On Fri, Mar 4, 2011 at 11:22 AM, Chris Copeland ch...@cope360.com wrote: I just recently completed a Google Checkout integration for my GAE app. The fact that you are on GAE makes no difference except that if you do a level 2 integration you will have to use your app-name.appspot.com URL for the callbacks since Google Checkout requires the callback URL to be secure. All that said, if I had it to do over, I would definitely go with Pay Pal (or someone else). Checkout seems to be an abandoned product within Google. There are long-standing bugs that prevent some users from paying and support (even for merchants) is almost nonexistent. -Chris On Fri, Mar 4, 2011 at 1:01 PM, anton savchuk anton.antoh...@gmail.com wrote: I see.. thank you. Could you recommend some third-party libraries? -- 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. -- 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. -- 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. -- Dr. Duong BaTien DBGROUPS BudhNet -- 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.
Re: [google-appengine] Re: Should I switch to the low level datastore api?
Hi Jeff: Which version of Objectify you use? I am also happy with Objectify and it works for me at version 2.2. I start from GAE sample guestbook and build from there up with Objectify rather than with JDO. I have some issue with version 2.2.1 and do not have enough time to dig into it. Thanks. Duong BaTien DBGROUPS and BudhNet On Sat, 2010-09-11 at 00:58 -0400, Jeff Schwartz wrote: I am also using Objectify having switched from the low level api because I wanted to codify my schemas (records) in pojos. I have to say that I am very happy with both its api and performance. And the Objectify commiters are really a nice bunch and very responsive when having posted to their board. On Fri, Sep 10, 2010 at 6:37 PM, mscwd01 mscw...@gmail.com wrote: Thanks for your replies. I took a closer a look at the requests using AppStats and found I was inadvertently querying entities in a loop. I rectified this and now request times are anything between 200ms and 450ms with the average request being about 350ms. I'm guessing this is not too bad? Also when checking the request time on the main dashboard, the times are always longer than that given by AppStats, why is this? Thanks again. On 10 Sep, 21:59, Ikai L (Google) ika...@google.com wrote: I think I can't type today. What I meant to say in my first email was there may be some performance benefit by switching to the low-level API, but the overhead introduced by JDO/JPA should be minimal in terms of queries and writes. On Fri, Sep 10, 2010 at 1:50 PM, gholler georgehol...@gmail.com wrote: I'm on a team that built a JDO app engine project that was fairly slow and then built a similar project using Objectify. We were very pleased with the performance. We were also careful to only index fields we queried and also let Objectify doing caching for us automatically. G -- 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.comgoogle-appengine%2Bunsubscrib e...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog:http://googleappengine.blogspot.com Twitter:http://twitter.com/app_engine Reddit:http://www.reddit.com/r/appengine -- 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. -- -- 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-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. -- 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.
Re: [google-appengine] Re: Should I switch to the low level datastore api?
On Sat, 2010-09-11 at 12:32 -0400, Jeff Schwartz wrote: They have applied numerous patches since releasing 2.2.1 so you might want to download their source, build it use that lib in your projects. Thanks. will do and Share with the community my finding and/or debugging. BaTien On Sat, Sep 11, 2010 at 11:01 AM, Duong BaTien duong.bat...@gmail.com wrote: Hi Jeff: Which version of Objectify you use? I am also happy with Objectify and it works for me at version 2.2. I start from GAE sample guestbook and build from there up with Objectify rather than with JDO. I have some issue with version 2.2.1 and do not have enough time to dig into it. Thanks. Duong BaTien DBGROUPS and BudhNet On Sat, 2010-09-11 at 00:58 -0400, Jeff Schwartz wrote: I am also using Objectify having switched from the low level api because I wanted to codify my schemas (records) in pojos. I have to say that I am very happy with both its api and performance. And the Objectify commiters are really a nice bunch and very responsive when having posted to their board. On Fri, Sep 10, 2010 at 6:37 PM, mscwd01 mscw...@gmail.com wrote: Thanks for your replies. I took a closer a look at the requests using AppStats and found I was inadvertently querying entities in a loop. I rectified this and now request times are anything between 200ms and 450ms with the average request being about 350ms. I'm guessing this is not too bad? Also when checking the request time on the main dashboard, the times are always longer than that given by AppStats, why is this? Thanks again. On 10 Sep, 21:59, Ikai L (Google) ika...@google.com wrote: I think I can't type today. What I meant to say in my first email was there may be some performance benefit by switching to the low-level API, but the overhead introduced by JDO/JPA should be minimal in terms of queries and writes. On Fri, Sep 10, 2010 at 1:50 PM, gholler georgehol...@gmail.com wrote: I'm on a team that built a JDO app engine project that was fairly slow and then built a similar project using Objectify. We were very pleased with the performance. We were also careful to only index fields we queried and also let Objectify doing caching for us automatically. G -- 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.comgoogle-appengine% 2Bunsubscrib e...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog:http://googleappengine.blogspot.com Twitter:http://twitter.com/app_engine Reddit:http://www.reddit.com/r/appengine -- 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
Re: [google-appengine] objectify-2.2.1 with GAE-1.3.6
Thanks.
I will repost it in the Objectify group after trying the new GAE-1.3.7
with objectify-2.2.1. The persistence is done on the entity Greeting
which extends the GenericDAO which extends the Objectify DAONase. I do
not even override the DAOBase constructor with OjectifyOpts.
Do not answer this post. Please give me few hours and suggestions in
Objectify group.
BaTien
DBGROUPS and BudhNet
On Sat, 2010-09-04 at 23:06 -0700, Jeff Schnitzer wrote:
1) Jeff is right, you should post this to the objectify list. The
objectify developers don't consistently monitor this list.
2) When you do, you should post your entity code, not your generic dao code.
3) Somehow you're trying to persist a field of type ObjectifyOpts.
You can't do that.
Jeff
On Sat, Sep 4, 2010 at 6:59 PM, Jeff Schwartz jefftschwa...@gmail.com wrote:
I believe you should try posting your question at
objectify-appeng...@googlegroups.com.
On Sat, Sep 4, 2010 at 4:23 PM, Duong BaTien duong.bat...@gmail.com wrote:
Hi:
I upgrade to Objectify-2.1.1 with GAE-1.3.6 and retest the guestbook
tutorial. I get the exception while persisting the greeting object to
the datastore. I notice the ObjectifyOpts is new in this 2.1.1 version.
[java] WARNING: /sign
[java] java.lang.IllegalArgumentException: opts:
com.googlecode.objectify.ObjectifyOpts is not a supported property type.
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedSingleValue(DataTypeUtils.java:184)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:157)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:123)
[java] at
com.google.appengine.api.datastore.Entity.setUnindexedProperty(Entity.java:300)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.setEntityProperty(FieldSaver.java:156)
[java] at
com.googlecode.objectify.impl.save.LeafFieldSaver.saveValue(LeafFieldSaver.java:94)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.save(FieldSaver.java:139)
[java] at
com.googlecode.objectify.impl.save.ClassSaver.save(ClassSaver.java:110)
[java] at
com.googlecode.objectify.impl.Transmog.save(Transmog.java:342)
[java] at
com.googlecode.objectify.impl.EntityMetadata.toEntity(EntityMetadata.java:230)
[java] at
com.googlecode.objectify.impl.ObjectifyImpl.put(ObjectifyImpl.java:195)
[java] at
com.budhnet.aas.service.process.GenericDao.put(GenericDao.java:140)
[java] at
com.budhnet.aas.service.process.Greeting.storeGreeting(Greeting.java:104)
[java] at
com.budhnet.aas.service.process.SignGuestbookServlet.doPost(SignGuestbookServlet.java:50)
My constructors of genericDAO are:
@SuppressWarnings(unchecked)
public GenericDao(){ // DAO without transaction
super();
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
@SuppressWarnings(unchecked)
public GenericDao(boolean transactional){ // DAO with transaction
super(transactional);
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
and constructors for the greeting are:
public Greeting() { super(); }
public Greeting(boolean transactional) { super(transactional); }
public Greeting(User author, String content, Date date) {
this.author = author;
this.content = content;
this.date = date;
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
The sigGuestbookServlet has:
Greeting greeting = new Greeting(user, content, new Date());
greeting.storeGreeting();
resp.sendRedirect(/guestbook.jsp);
Any suggested solution?
Thanks
BaTien
DBGROUPS and BudhNet
--
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.
--
--
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-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.
--
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
Re: [google-appengine] objectify-2.2.1 with GAE-1.3.6
Thnaks.
I will repost it in the Objectify group after trying the new GAE-1.3.7
with objectify-2.2.1. The persistence is done on the entity Greeting
which extends the GenericDAO which extends the Objectify DAONase. I do
not even override the DAOBase constructor with OjectifyOpts.
Do not answer this post. Please give me few hours and suggestions in
Objectify group.
BaTien
DBGROUPS and BudhNet
On Sat, 2010-09-04 at 21:59 -0400, Jeff Schwartz wrote:
I believe you should try posting your question at
objectify-appeng...@googlegroups.com.
On Sat, Sep 4, 2010 at 4:23 PM, Duong BaTien duong.bat...@gmail.com
wrote:
Hi:
I upgrade to Objectify-2.1.1 with GAE-1.3.6 and retest the
guestbook
tutorial. I get the exception while persisting the greeting
object to
the datastore. I notice the ObjectifyOpts is new in this 2.1.1
version.
[java] WARNING: /sign
[java] java.lang.IllegalArgumentException: opts:
com.googlecode.objectify.ObjectifyOpts is not a supported
property type.
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedSingleValue(DataTypeUtils.java:184)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:157)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:123)
[java] at
com.google.appengine.api.datastore.Entity.setUnindexedProperty(Entity.java:300)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.setEntityProperty(FieldSaver.java:156)
[java] at
com.googlecode.objectify.impl.save.LeafFieldSaver.saveValue(LeafFieldSaver.java:94)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.save(FieldSaver.java:139)
[java] at
com.googlecode.objectify.impl.save.ClassSaver.save(ClassSaver.java:110)
[java] at
com.googlecode.objectify.impl.Transmog.save(Transmog.java:342)
[java] at
com.googlecode.objectify.impl.EntityMetadata.toEntity(EntityMetadata.java:230)
[java] at
com.googlecode.objectify.impl.ObjectifyImpl.put(ObjectifyImpl.java:195)
[java] at
com.budhnet.aas.service.process.GenericDao.put(GenericDao.java:140)
[java] at
com.budhnet.aas.service.process.Greeting.storeGreeting(Greeting.java:104)
[java] at
com.budhnet.aas.service.process.SignGuestbookServlet.doPost(SignGuestbookServlet.java:50)
My constructors of genericDAO are:
@SuppressWarnings(unchecked)
public GenericDao(){ // DAO without transaction
super();
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
@SuppressWarnings(unchecked)
public GenericDao(boolean transactional){ // DAO with
transaction
super(transactional);
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
and constructors for the greeting are:
public Greeting() { super(); }
public Greeting(boolean transactional)
{ super(transactional); }
public Greeting(User author, String content, Date date) {
this.author = author;
this.content = content;
this.date = date;
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
The sigGuestbookServlet has:
Greeting greeting = new Greeting(user, content, new
Date());
greeting.storeGreeting();
resp.sendRedirect(/guestbook.jsp);
Any suggested solution?
Thanks
BaTien
DBGROUPS and BudhNet
--
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.
--
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send
[google-appengine] objectify-2.2.1 with GAE-1.3.6
Hi:
I upgrade to Objectify-2.1.1 with GAE-1.3.6 and retest the guestbook
tutorial. I get the exception while persisting the greeting object to
the datastore. I notice the ObjectifyOpts is new in this 2.1.1 version.
[java] WARNING: /sign
[java] java.lang.IllegalArgumentException: opts:
com.googlecode.objectify.ObjectifyOpts is not a supported property type.
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedSingleValue(DataTypeUtils.java:184)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:157)
[java] at
com.google.appengine.api.datastore.DataTypeUtils.checkSupportedValue(DataTypeUtils.java:123)
[java] at
com.google.appengine.api.datastore.Entity.setUnindexedProperty(Entity.java:300)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.setEntityProperty(FieldSaver.java:156)
[java] at
com.googlecode.objectify.impl.save.LeafFieldSaver.saveValue(LeafFieldSaver.java:94)
[java] at
com.googlecode.objectify.impl.save.FieldSaver.save(FieldSaver.java:139)
[java] at
com.googlecode.objectify.impl.save.ClassSaver.save(ClassSaver.java:110)
[java] at
com.googlecode.objectify.impl.Transmog.save(Transmog.java:342)
[java] at
com.googlecode.objectify.impl.EntityMetadata.toEntity(EntityMetadata.java:230)
[java] at
com.googlecode.objectify.impl.ObjectifyImpl.put(ObjectifyImpl.java:195)
[java] at
com.budhnet.aas.service.process.GenericDao.put(GenericDao.java:140)
[java] at
com.budhnet.aas.service.process.Greeting.storeGreeting(Greeting.java:104)
[java] at
com.budhnet.aas.service.process.SignGuestbookServlet.doPost(SignGuestbookServlet.java:50)
My constructors of genericDAO are:
@SuppressWarnings(unchecked)
public GenericDao(){ // DAO without transaction
super();
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
@SuppressWarnings(unchecked)
public GenericDao(boolean transactional){ // DAO with transaction
super(transactional);
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
and constructors for the greeting are:
public Greeting() { super(); }
public Greeting(boolean transactional) { super(transactional); }
public Greeting(User author, String content, Date date) {
this.author = author;
this.content = content;
this.date = date;
clazz = ((Class) ((ParameterizedType)
getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
The sigGuestbookServlet has:
Greeting greeting = new Greeting(user, content, new Date());
greeting.storeGreeting();
resp.sendRedirect(/guestbook.jsp);
Any suggested solution?
Thanks
BaTien
DBGROUPS and BudhNet
--
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] paypalx-gae-toolkit with SDK 1.3.5
Hi: I am trying to compile and runserver of sample PicMart in paypalx=gae-toolkit with the latest SDK 1.3.5. The comile target is ok except a warning, the runserver target has error and the access via http://localhost:8080/ has 403 error Problem accessing FORBIDDEN. Does anyone have the answer? Thanks Duong BaTien DBGROUPS and BudhNet Warning for ant javc: [javac] /data/picMart/build.xml:112: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 2 source files to /data/picMart/war/WEB-INF/classes BUILD SUCCESSFUL Error for ant runserver: datanucleusenhance: [enhance] DataNucleus Enhancer (version 1.1.4) : Enhancement of classes [enhance] DataNucleus Enhancer completed with success for 0 classes. Timings : input=241 ms, enhance=0 ms, total=241 ms. Consult the log for full details [enhance] DataNucleus Enhancer completed and no classes were enhanced. Consult the log for full details runserver: [java] Jul 19, 2010 8:11:35 AM com.google.appengine.tools.info.LocalVersionFactory getVersion [java] INFO: Could not find API version from /data/picMart/war/WEB-INF/lib/.svn [java] java.util.zip.ZipException: error in opening zip file [java] at java.util.zip.ZipFile.open(Native Method) [java] at java.util.zip.ZipFile.init(ZipFile.java:114) [java] at java.util.jar.JarFile.init(JarFile.java:135) [java] at java.util.jar.JarFile.init(JarFile.java:99) [java] at com.google.appengine.tools.util.ApiVersionFinder.findApiVersion(ApiVersionFinder.java:37) [java] at com.google.appengine.tools.info.LocalVersionFactory.getVersion(LocalVersionFactory.java:65) [java] at com.google.appengine.tools.info.UpdateCheck.getLocalVersion(UpdateCheck.java:116) [java] at com.google.appengine.tools.info.UpdateCheck.checkForUpdates(UpdateCheck.java:95) [java] at com.google.appengine.tools.info.UpdateCheck.doNagScreen(UpdateCheck.java:168) [java] at com.google.appengine.tools.info.UpdateCheck.maybePrintNagScreen(UpdateCheck.java:136) [java] at com.google.appengine.tools.development.DevAppServerMain $StartAction.apply(DevAppServerMain.java:150) [java] at com.google.appengine.tools.util.Parser $ParseResult.applyArgs(Parser.java:48) [java] at com.google.appengine.tools.development.DevAppServerMain.init(DevAppServerMain.java:113) [java] at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:89) [java] Jul 19, 2010 8:11:38 AM com.google.apphosting.utils.jetty.JettyLogger info [java] INFO: Logging to JettyLogger(null) via com.google.apphosting.utils.jetty.JettyLogger [java] Jul 19, 2010 8:11:38 AM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml [java] INFO: Successfully processed /data/picMart/war/WEB-INF/appengine-web.xml [java] Jul 19, 2010 8:11:38 AM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml [java] INFO: Successfully processed /data/picMart/war/WEB-INF/web.xml [java] Jul 19, 2010 8:11:41 AM com.google.appengine.tools.development.DevAppServerImpl start [java] INFO: The server is running at http://localhost:8080/ -- 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.
Re: [google-appengine] Re: Google Apps and BigTable
Hi: This is an interesting topic. I am a retired entrepreneur, professional software developer, professional economist, economic professor and professional engineer. I am planning to use cloud technology to democratize the AwakeningBudh or Innate Intelligence in living persons. All emotions are conditioned driven by your view (Understanding) and motive (Volitional Formation) which are driven by Binding Thoughts. There is binding and detachment-born thought in a sense that once a thought and its action is completed, there is No Hanging Effect known by many Loving-Kindness Samaritan while the binding though will continuously haunt one's conscience (which is a part of the Innate Budh) until one's Innate Budh is awaken and do something about it. Binding Thought is a slavery pattern (fears, phobias, innumerable unmanageable desires of the grasper and the grasped, etc) while detachment-born thought enables one see Thing As It Is, outside the conditioned box of slavery bounded in the Name of Anything. Thought is conditioned. When I call your name you can answer right away. When I ask if you know so and so over 40 years ago, you may take some time to recall. If thought is conditioned, what is the Source of Thought? That is the Innate Budh (Intelligence) that we prove it is a Sine Qua Non of Living, since without some form of Intelligence, there is No Living. It is an Observable Truth or mathematical axiom. From that Observable Truth like Newton Third Law of Action and Reaction, one can discover a process according to natural laws (like gravity force) leading the Right Living toward Happiness and Evolution where Dependent Nature is a part of the natural laws governing all processes from gross manifestations to minute level of a thought. That Dependent Nature enables one see Thing As It Is where 1 + 1 2 (a win-win Strategic Moment), symbolized in 2 Knights on the same horse in the symbol of Knights Templar. Greed and Passion are transformed into Sharing Happiness - Mitigating Sufferings called ComPassion (or Common Vibration of Energy) of one's Inner Circle and circles of inner circles. Via democratizing the AwakeningBudh, one can see the Inner Dignity of Living and have the Right Understanding and Right Thought to be a part of the Crowd Wisdom that no tyranny and extreme dark force of violence, of To me Through Me and Only Me in the past can be repeated. Software open source is a movement toward that direction. Hope each one of us can be a soldier of Sharing Happiness - Mitigating Sufferings that go beyond the symbol of Tao's Yin-Yang of Evolution then Degeneration. Duong BaTien DBGROUPS and BudhNet On Mon, 2010-05-24 at 04:57 -0700, gops wrote: @keren, i may not have economical expertise , but one thing is sure , as long as this world is running from greed and passion of people ( imho, 2 holiest emotion ) , the economy is not going to down for sure. On May 24, 4:52 pm, gops patelgo...@gmail.com wrote: @hawkett last line was the perfect answer to @keren. instead of making a central system on cloud , designing a software that is very highly distributed using highest encryption standard is a way to go. on some level , people athttp://www.joindiaspora.com/are doing that thing at social networking level. ( personally i dont think doing this on top of other http or https protocol is good idea. even though creating/defining protocol is hard work , it should be done directly on top of tcp/ip level. ) that way, i own my own server at my own location with my own data fully encrypted and accessible only to me. then i delegate data through defined protocol to other person or system ( be it a company , a bank , a friend , a community etc.. ) with different level of data and security access. same way, other system, users and bank etc will delegate their data to my server to similar encryption channels. distributing data this way will remove scalability need altogether. and application complexity will reduce dramatically as they do not have to take care of 1000's of connection or users. but it will arise problem for myself to maintain my server , will force to learn a new software etc and learn the system, may be your own private virtual server is a new commodity of the future. my two cents. :D On May 24, 4:08 pm, hawkett hawk...@gmail.com wrote: A small issue if the economy goes down the drain on the scale you are talking about is that an internet where everyone has the capability to connect to a cloud system is going to be difficult to maintain. It's not going to be easy for google to make money, for individuals to pay their internet bills, for internet companies to continue to deliver access - indeed you may find it difficult for yourself to make money or pay for the developers you are proposing to hire. What value will money have? How will google pay its employees to continue to deliver app engine - ad revenues
[appengine-java] Open Source FullText Search in Objectify Example
I got it. It may happen at googlecode maintenance time. Thanks BaTien Thanks for sharing your code. I try to get the source code, but get the following error: [bat...@dev2 restSearch]$ svn co http://fulltext-search-in- objectify.googlecode.com/svn/trunk/ fullTextSearch svn: PROPFIND request failed on '/svn/!svn/bln/7' svn: PROPFIND of '/svn/!svn/bln/7': 502 Bad Gateway (http://fulltext- search-in-objectify.googlecode.com) Let us know when it is fixed. Duong BaTien DBGROUPS and BudhNet On Wed, 2010-05-05 at 17:06 -0300, nicolas melendez wrote: This a migration from JDO to Objectify for the fulltext search example from this post: http://googleappengine.blogspot.com/2010/04/making-your-app- searchable-using-self.html? utm_source=feedburnerutm_medium=feedutm_campaign=Feed: +GoogleAppEngineBlog+(Google+App+Engine+Blog) The idea and CORE CODE is from: Nico Güttler, Dominic Jansen, Raphael Bauer (http://corporate.scisurfer.com/) I only MIGRATED it to OBJECTIFY Framework, thats my colaboration. Thats the open source magic :) here the url : http://code.google.com/p/fulltext-search-in-objectify/ Nicolás Meléndez -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Open Source FullText Search in Objectify Example
Hi: Thanks for sharing your code. I try to get the source code, but get the following error: [bat...@dev2 restSearch]$ svn co http://fulltext-search-in- objectify.googlecode.com/svn/trunk/ fullTextSearch svn: PROPFIND request failed on '/svn/!svn/bln/7' svn: PROPFIND of '/svn/!svn/bln/7': 502 Bad Gateway (http://fulltext- search-in-objectify.googlecode.com) Let us know when it is fixed. Duong BaTien DBGROUPS and BudhNet On Wed, 2010-05-05 at 17:06 -0300, nicolas melendez wrote: This a migration from JDO to Objectify for the fulltext search example from this post: http://googleappengine.blogspot.com/2010/04/making-your-app- searchable-using-self.html? utm_source=feedburnerutm_medium=feedutm_campaign=Feed: +GoogleAppEngineBlog+(Google+App+Engine+Blog) The idea and CORE CODE is from: Nico Güttler, Dominic Jansen, Raphael Bauer (http://corporate.scisurfer.com/) I only MIGRATED it to OBJECTIFY Framework, thats my colaboration. Thats the open source magic :) here the url : http://code.google.com/p/fulltext-search-in-objectify/ Nicolás Meléndez -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: JAXB
This may be the one you are looking for. It works with JAXB 2.2, Jersey and GAE http://tugdualgrall.blogspot.com/ Duong BaTien DBGROUPS and BudhNet On Fri, 2010-04-30 at 15:38 +0430, Łukasz Woźniczka wrote: This link is useful. http://stackoverflow.com/questions/1955396/whats-the-easiest-way-to- persist-java-objects But i'm looking for implementation on google app engine... -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: JAXB
Please share your example if you can. We will share our solution at the right time for using: (1) GAE, Guice, Objectify, Jersey REST and JAXB at server side, (2) Jersey REST client, JSONP in GWT 2. Thanks. BaTien On Fri, 2010-04-30 at 22:41 +0900, seleronm wrote: Hi, That's great information I tried to create a simple example though this can't begin to compete with that link Hope some of this helps thanks. This may be the one you are looking for. It works with JAXB 2.2, Jersey and GAE http://tugdualgrall.blogspot.com/ Duong BaTien DBGROUPS and BudhNet This link is useful. http://stackoverflow.com/questions/1955396/whats-the-easiest-way-to- persist-java-objects But i'm looking for implementation on google app engine... -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+ unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google- appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Why should app startup times be a problem.
Hi: On Wed, 2010-03-31 at 22:51 -0700, Jeff Schnitzer wrote: On Wed, Mar 31, 2010 at 6:41 PM, jd jdpatter...@gmail.com wrote: On Apr 1, 3:14 am, Jeff Schnitzer j...@infohazard.org wrote: What does Twig do when someone issues a type-less query? datastore.find().addFilter(color, EQUAL, green). returnResultsNow() The expression above is actually not possible to enter using the fluent commands. You can only set a filter on the interface that is returned from calling FindCommand.type(Class?) It is also illegal according to the datastore docs for a Query with no kind: Currently the only operations supported on a kind-less query are filter by __key__, ancestor, and order by __key__ ascending In other words, Twig cannot perform the simple query: IterableObject foo = ofy.query().ancestor(yourobject); This is the required pattern shown in Google IO scalable application for GAE. Duong BaTien DBGROUPS and BudhNet If you ever want to support something like this, you will need a registration process. If you ever want to support true polymorphic queries, you will need a registration process. Don't claim this short-sightedness as a feature. Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Objectify-Appengine 2.1 released, supports Partial Indexes
Hi:
Congratulation and thank for tremendous efforts from the Objectify Team.
By the way, has any one attempted Objectify with possible very large
index of subscribers and publishers of web-hook pub-sub (Google
PubSubHubbub of Atom or short message twitter style).
Thanks
Duong BaTien
DBGROUPS and BudhNet
On Thu, 2010-03-25 at 13:45 -0700, Jeff Schnitzer wrote:
Today we released Objectify v2.1, the latest version of our opensource
replacement for JDO/JPA on the Google App Engine datastore.
This version includes a major new feature, Partial Indexes. If you
aren't sure what partial indexes are, the Wikipedia page
(http://en.wikipedia.org/wiki/Partial_index) describes them so:
A partial index, also known as filtered index is a database index
which has some condition applied to it such that it only includes a
portion of the rows in the table. This can allow the index to remain
small even though the table may be rather large, and have fairly
extreme selectivity.
Here is an example of an Objectify entity using partial indexes:
public class Player {
@Id Long id;
// Simple conditions: IfFalse, IfTrue, IfZero, IfNull, etc
@Unindexed(IfFalse.class) boolean admin;
// Smarter - sensitive to the actual default value
@Unindexed(IfDefault.class) Team team = Team.NOTCHOSEN;
// You can make your own conditions
@Unindexed(IfCustomCondition.class) Status status;
static class IfCustomCondition extends ValueIfStatus {
public boolean matches(Status value) {
return (value == Status.DEAD || value == Status.RETIRED);
}
}
}
Why should you care about optimizing indexes?
All queries in the datastore require indexes, which are a sort of
reverse-mapping from value to key. These indexes occupy space and
consume cpu resources whenever an entity is written to the datastore.
With the addition of just a few indexes, this cost quickly doubles or
triples the cost of storing the original entity:
* A basic entity with no indexes costs 48 api_cpu_ms to store.
* Each single-property indexed field adds an additional 17 api_cpu_ms.
This number appears stable and consistent; appengine seems to have a
static formula for computing datastore costs. Storage size costs are
harder to measure, but from watching mailing list traffic it seems
quite easy to double or triple your storage size with unnecessary
indexes.
When should you care about optimizing indexes?
* Removing unnecessary indexes will not make writes faster, it will
make them /cheaper/. All indexes are written in parallel, so indexes
do not add latency to writes. Instead, indexes add $ to the bill you
get at the end of the week - and push you closer to your quota limits.
* If your application has relatively small quantities of relatively
static data, index optimization is probably pointless. On the other
hand, if you have large data volumes or heavy write loads, you must
carefully choose your indexes (or be very rich).
Do I need partial indexes, as opposed to just declaring whole fields
indexed or not?
It depends on your dataset and your queries. In the Player example
above, partial indexes can be extremely effective:
* You only ever filter on the admin field for actual admins, and most
players are not admins.
* You only ever filter on the team field for players who have chosen
a team, and the bulk of players are not associated with a team.
* You only ever filter on the status field for players who have
active statuses, and you have a large number of inactive players.
Objectify's support for partial indexes also has the ability to
determine index behavior based on the whole entity. This allows you
to perform certain kinds of limited multiple-property queries
(including double inequality queries) without creating a
multi-property index. As an example, it is very easy to model this
index from the Wikipedia page:
create index partial_salary on employee(age) where salary 2100;
An example of this is documented in the Objectify manual.
Thanks,
The Objectify Team
Jeff, Scott, and Matt
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Objectify - Twig - approaches to persistence
Hi Jeff and John: Wow! This is the spirit of open source where we can focus on what we are interesting in to Share our unique comparative advantages while learning and leveraging on others for the benefits of the Whole. Thanks guys. Duong BaTien DBGROUPS and BudhNet On Sun, 2010-03-14 at 19:27 +0700, John Patterson wrote: On 13 Mar 2010, at 11:00, Jeff Schnitzer wrote: since you can (and IMNSHO probably should) always disable automatic activation and refresh the graph manually. Although I dislike premature optimisations such as this note that you can configure Activation to not activate any Objects by default. After you explained the concept of uninitialized entities (the brief blurb in your docs really isn't enough), I actually rather like your solution! I might even implement something similar in Objectify. But I really think you need to document the hell out of the issues surrounding them. It is very very easy to corrupt data. Despite all the talk about differences in philosophy and the down playing of the features in Twig I can see from the Objectify mailing list that discussion has already started on how it would be possible to add support for direct references and async parallel commands. Be very careful not to end up with an API that bulges with features that are tacked on as an after thought. The Objectify Query API as it is now would need to explode with permutations. Perhaps it is best to stick to the goal of being a more usable object capable interface to the low-level API? Objectify does this very well. When Twig started as not much more than a thin wrapper around the low- level interface and grew in complexity as more high level Object oriented features were added it became obvious that mixing direct references and low-level Keys and Queries in the same API is just not manageable. So I stripped out almost all the low-level references and the result is a very clean, focused API. Adding a collection of helper functions to Objectify for things like merging OR queries would very soon become unorganised and make exploring the API difficult. You should probably make a decision about the design goals of Objectify and stay true to it. There is always the option of building a higher-level interface on top of Objectify - now that would be interesting! In Twig you have the option to drop down to use the low- level datastore service if you really need to - but the necessity for this has decreased a lot with the final release 1.0 Although this our-answer-to-the-great-question-is-the-only-logical-one banter is terrific fun it might make sense to work on some functionality in common. Scott and I briefly mentioned making a common profiling ApiProxy to help understand the performance of your app. I've made a quick start on this but it really is a feature that makes sense not just for Twig. If the feature sets of Twig and Objectify end up converging over time - albeit with differences in default settings - it begs the question if there might be some way to cooperate on higher level functionality also. OR queries haven't been a pain point. Maybe they will be in the future, in which case we'll consider adding the feature. We are content to wait for the request. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] What is the purpose of keyName? (Low-level API)
Hi Jeff and Max: Sorry to jump in this debate on the use of system generated Long id and user-provided long id and String name. I found the discussion is useful from best practice. I leverage Objectify and try to re-do our data model. Originally, i chose the route of String name for user, role and group to enforce the unique name of the entity Key, plus long id provided from a simple ConcurrentHashMap Singleton. But i feel that the home-grown ConcurrentHashMap Singleton may not be as robust and scalable as the generated Long id, recognizing that the generated id is not contiguous. So i decided the use of String name of natural uniqueness such as email for user lock-in and generated Long id is for others. Please comment and/or siggestion. Duong BaTien DBGROUPS and BudhNet On Mon, 2010-02-22 at 13:52 -0800, Jeff Schnitzer wrote: On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google) maxr+appeng...@google.com wrote: user-defined long-id keys are not quite as easily used. You either need to commit to not letting the datastore generate ids for that kind or you need to reserve a batch of ids using the DatastoreService.allocateIds method. Otherwise you run the risk of a silent collision. There is no such risk with user-defined string keys. Right, but if the user has a natural key (long, String, whatever) they won't be using the generator anyways. There are plenty of natural long keys in the world... facebook userid being a popular one. FWIW, Objectify makes the distinction between ids of type Long, which can be null and thus autogenerated, and long (the primitive) which cannot be autogenerated. I really hadn't intended to plug Objectify here, really! Valid point about renaming, but going back to the example I provided, the datastore does not distinguish between inserts and updates. The only way you can guarantee that an entity was inserted, and therefore the only way you can guarantee the uniqueness of the name, is to use a user-defined key. If you're mapping id to name it will be possible to create two entities with the same name. It's of course up to you to decide how important this is to defend against, but without the ability to provide your own id you wouldn't get to make this choice, and without the ability to provide your own string id you wouldn't be able to add some application-specific meaning to this choice. I totally agree with you WRT user-defined vs generated values, I just don't see anything wrong with using the long id as a user-defined value. Just make sure you never ask for a generated one. Seems pretty straightforward. Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] What is the purpose of keyName? (Low-level API)
On Mon, 2010-02-22 at 15:13 -0800, Jeff Schnitzer wrote: It sounds like you were trying to generate long ids from an in-memory singleton, which is a perilous thing to do... there is never a guarantee that there is only a single instance of your application running on a single machine in appengine. In general... if you have a natural key, use it, otherwise use the generator. Most data modelers say you shouldn't even use natural keys (like email), since what you think is a natural key today turns out to be a mutable field tomorrow (ie, new requirement: users can change email addresses). I'm pretty partial to that philosophy myself, and rarely use natural keys - facebook userid being my main exception. Jeff Yes, i am aware of this. Google uses it and calls the unique name within the system the canonical name whether the name is an email or just a convenient id like the Wave id. I copy google idea. Any comment? Thanks BaTien On Mon, Feb 22, 2010 at 2:46 PM, Duong BaTien duong.bat...@gmail.com wrote: Hi Jeff and Max: Sorry to jump in this debate on the use of system generated Long id and user-provided long id and String name. I found the discussion is useful from best practice. I leverage Objectify and try to re-do our data model. Originally, i chose the route of String name for user, role and group to enforce the unique name of the entity Key, plus long id provided from a simple ConcurrentHashMap Singleton. But i feel that the home-grown ConcurrentHashMap Singleton may not be as robust and scalable as the generated Long id, recognizing that the generated id is not contiguous. So i decided the use of String name of natural uniqueness such as email for user lock-in and generated Long id is for others. Please comment and/or siggestion. Duong BaTien DBGROUPS and BudhNet On Mon, 2010-02-22 at 13:52 -0800, Jeff Schnitzer wrote: On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google) maxr+appeng...@google.com wrote: user-defined long-id keys are not quite as easily used. You either need to commit to not letting the datastore generate ids for that kind or you need to reserve a batch of ids using the DatastoreService.allocateIds method. Otherwise you run the risk of a silent collision. There is no such risk with user-defined string keys. Right, but if the user has a natural key (long, String, whatever) they won't be using the generator anyways. There are plenty of natural long keys in the world... facebook userid being a popular one. FWIW, Objectify makes the distinction between ids of type Long, which can be null and thus autogenerated, and long (the primitive) which cannot be autogenerated. I really hadn't intended to plug Objectify here, really! Valid point about renaming, but going back to the example I provided, the datastore does not distinguish between inserts and updates. The only way you can guarantee that an entity was inserted, and therefore the only way you can guarantee the uniqueness of the name, is to use a user-defined key. If you're mapping id to name it will be possible to create two entities with the same name. It's of course up to you to decide how important this is to defend against, but without the ability to provide your own id you wouldn't get to make this choice, and without the ability to provide your own string id you wouldn't be able to add some application-specific meaning to this choice. I totally agree with you WRT user-defined vs generated values, I just don't see anything wrong with using the long id as a user-defined value. Just make sure you never ask for a generated one. Seems pretty straightforward. Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Building Scalable Complex App
Please see the answer i sent out yesterday for a proper solution.
Duong BaTien
DBGROUPS and BudhNet
On Sat, 2010-01-30 at 01:14 -0800, digitalsam007 wrote:
I failed to make this code work. It seems that the MessageIndex object
is not getting persisted when i call tx.commit().
Any help in this regard will be appreciated.
Thanks
On Jan 17, 12:26 am, Duong BaTien duong.bat...@gmail.com wrote:
Hi:
Following is my sketch for the Message and MessageIndex. Please advise
and if possible, sketch out the Java version of set intersection from
the presentation. Have not time to try anything yet; but the design is
very significant for proper data modeling. The JDO version of the
presentation uses query.setFilter(receivers == 'foo') which i do not
see in the API.
public class MessageIndex { // create MessageIndex to the parent Message
private Key parent; private String keyKind; private long id;
@PrimaryKey
@Persistent(ValueStrategy = IdGeneratorStrategy.IDENTITY)
private KeyFactory.createKey(parent, keyKind, id) key;
@Persistent private ListString receivers;
// constructor to create MessageIndex linked to Message
public MessageIndex(Key parent, String keyKind, long id) {
this.parent = parent; this.keyKind = keyKind; this id = id;
}
public class Message {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key key
@Persistent private String sender;
@Persistent private String body;
// a user create a message to a list of receivers
public static Message createMessage(String userId, String body,
ListString receivers) {
tx.begin()
this.body = body;
MessageIndex index = new MessageIndex(key, key,getKind(), key.getId
());
index.setReceivers(receivers);
tx.commit();
}
// query to get all messages sent to a user foo
public ListMessage getMessagesSentToUserId(String userId) {
ListMessage results = null
tx.begin();
Query q = pm.newQuery(MessageIndex.class);
q.addFilter(receivers, Query.FilterOperator.EQUAL, foo);
q.setKeyOnly();
// query the Message for all messages filtered by parent of
MessageIndex key
Query query = pm.newQuery(Message.class);
query.addFilter(key, Query.FilterOperator.EQUAL, q.execute
().getParent());
results = (ListMessage) query.execute();
tx.commit();
}
}
Thanks
Duong BaTien
DBGROUPS and BudhNet
On Wed, 2010-01-13 at 16:26 -0800, Jason (Google) wrote:
It's been awhile since I've seen this video, so I'll have to go back
to re-watch it in order to answer your question completely, but I'd be
interested in seeing what you've sketched out so far and happy to give
you my feedback on it.
- Jason
On Tue, Jan 12, 2010 at 3:52 PM, Duong BaTien duong.bat...@gmail.com
wrote:
Hi Jason, the author Brett Slatkin and others:
1) For the list property, the video shows simple example of
standard 1:n
Message Receivers in python and Java. It then demonstrates a
very
efficient technique of Message and MessageIndex with the query
of
MessageIndex in python (NO Java from then on). I look at both
the low
level datastore with Query.setKeyOnly() and the query select
id from
to get the results of ListKey, then go through the loop to
get the
receivers. I may miss something, since the python code looks
so clean.
But once you are in any environment, it is very expensive to
switch.
This technique has major impact in data modeling.
2) Again for the set intersection, the python code looks so
clean. I
roughly sketch what need to be done on the Java side with
either low
level of datastore or with JDO. It is still not elegant as the
shown
codes. The demos are also in python. Again, the technique of
merge join
will have very significant impact on data modeling that GAE
may surpass
other platforms.
Haven't put enough time in it yet, I wonder if any one has
worked out
the demos in Java and suggested best practices in data
modeling for a
complex large application. The job Brett Slatkin sets out to
do has not
completed without the Java codes since GAE now supports Java.
Thanks
Duong BaTien
DBGROUPS and BudhNet
On Tue, 2010-01-12 at 14:13 -0800, Jason (Google) wrote:
Can you be more specific about what you're trying to
accomplish so we
don't have to search through the video to find what you're
looking
for? Or, at least provide
Re: [appengine-java] Question: best practice to persist medium-large data?
Thanks Jeff.
There seems to be something at odd:
On Tue, 2010-01-26 at 16:40 -0800, Jeff Schnitzer wrote:
Here's the Objectify version of what's described in the video, capable
of a photo-equivalent of million user fanout:
class Album {
@Id Long id;
String name;
}
class PhotoIndex {
@Id Long id;
@Parent OKeyAlbum album;
SetOKeyPhoto photos;
}
class Photo {
@Id Long id;
String caption;
String blobStoreKey;
}
If you want to ask what albums are this photo in? (equivalent to
what messages are waiting for me in the video), you query like this:
OQueryPhotoIndex query =
createQuery(PhotoIndex.class).filter(photos, photoKey);
ListOKeyAlbum keys = ofy.prepareKeysOnly(query).asList();
ListAlbum albums = ofy.get(keys);
Jeff
In the above query to ask what albums are this photo in, I wonder if it
is legitimate to cast List of PhotoIndex keys with ListOKeyAlbum so
you can get a particular photoKey in a list of albums.
Using the same structure for User, MessageIndex and Message, the query
seems to ask for a list of users, a particular message is sent to?
class User {
@Id Name userId;
}
class MessageIndex {
@Id Long messageIndexId;
@Parent OKeyUser userKey;
ListOKeyMessage messageKeys;
}
class Message {
@Id Long messageId;
String ccontent;
}
To query the list of users a particular messageKey is sent to:
OQueryMessageIndex query =
ObjectifyService.createQuery(MessageIndex.class).filter(messageKeys,
messageKey);
ListOKeyUser userKeys = ofy.prepareKeysOnly(query).asList();
ListUser users = ofy.get(userKeys);
To query what messages are waiting for me:
OQueryMessageIndex query = ObjectifyService.createQuery
(MessageIndex.class).filter(userKey, meKey);
ListOKeyMessage listOfMessageKeys = ofy.prepareKeysOnly
(query).asList();
// iterate through listOfMessageKeys and each iteration, get a batch of
messages sent to meKey?
Can GQL of python be used in Objectify?
Thanks
Duong BaTien
DBGROUPS and BudhNet
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Question: best practice to persist medium-large data?
Hi Jeff:
I am here again and have put sometime in Objectify. Thanks for taking
pain at different design patterns. Please let the list known your effort
in the good idea #2, especially in the social graph set intersections
and union.
Duong BaTien
DBGROUPS and BudhNet
On Tue, 2010-01-26 at 14:19 -0800, Jeff Schnitzer wrote:
On Mon, Jan 25, 2010 at 11:52 PM, John Patterson jdpatter...@gmail.com
wrote:
This is why you configure what type of relationship is used using: @Embed,
@Entity(PARENT), @Entity(CHILD) or @Entity(INDEPENDENT)
So you have the flexibility to choose configuration _without_ rewriting your
code. Very important difference.
The problem is that it *isn't* as simple as just changing an
annotation. Not in appengine, at any rate. It works in the simple
case (good for demos and sample apps), but you start to notice edge
cases:
* In some representations you can add a Photo to an Album in a
transaction, in some representations you can't.
* In some representations, multiple queries are required to fetch a
fetch an Album containing a Photo.
* Each representation has a completely different query syntax.
Twig exposes the datastore Query object, which means the developer
gets the full brunt of this exposure.
I don't want to say that it isn't possible to build a system that
abstracts entities into a sophisticated object graph - clearly, we
have JDO JPA. What I'm saying is that the people who created JDO
JPA are not idiots (although I do think the creators of JDO's
annotations are aesthetically challenged). The reason JDO has all
that complexity and endless configuration and query languages and
fetch groups and proxies and detaching and whatnot is because that's
what you need to abstract an arbitrary entity graph.
Currently the first type of representation is not an option. I do want to
add this as it makes very large collections that change often much more
efficient. When it is added you could reconfigure your data schema by
changing a single annotation. Such a change in Objectify would require the
developer to rewrite their entire data layer
You can never just reconfigure your data schema with a single
annotation, both for the reasons above and because you probably have
real-world data to migrate. And real-world constraints demand a
particular schema!
Let's actually answer the original poster's question - how do you
model a photo album? I hope he's still listening :-)
The first question is how you should model it in the datastore? I'll
use Objectify's syntax here because it corresponds directly to the
datastore representation.
Actually, let's start by describing how you SHOULDN'T model a photo album.
-
BAD IDEA #1:
class Album {
@Id Long id;
String name;
ListOKeyPhoto photos;
}
class Photo {
@Id Long id;
String caption;
String blobStoreKey;// key to GAE's blobstore
}
Fetching photos in an album (again, Objectify syntax but equivalent to
the datastore operation) is:
ListPhoto fetched = ofy.get(album.photos);
There are two reasons why this is a bad idea:
1) You now have a hard limit of 5,000 photos per album, established by GAE.
2) Every time you load an Album, you must load the entire set of
Photo keys. Want to generate a list of Album names? You have to load
all that key data, orders of mangitude more data than what you want.
-
BAD IDEA #2:
class Album {
@Id Long id;
String name;
}
class Photo {
@Id Long id;
@Parent OKeyAlbum album;
String caption;
String blobStoreKey;
}
This stores the Photo with the Album embedded in the Photo's Key as an
ancestor, making Photo part of the Album's entity group. At first
glance, this seems kinda cool and you can now do transactions across
Albums and Photos.
Fetching photos in an album:
OQueryPhoto query = createQuery(Photo.class).ancestor(albumKey);
ListPhoto fetched = ofy.prepare(query).asList();
The problem is what happens when you want to move a Photo from one
Album to another. You can't just change the parent. You must delete
the Photo entity and create a whole new Photo entity with the new
parent Album. And if the Photo has Comments or other referring
entities? All those comments need to be repointed at the new Photo.
A mess.
-
GOOD IDEA:
class Album {
@Id Long id;
String name;
}
class Photo {
@Id Long id;
OKeyAlbum album;
String caption;
String blobStoreKey;
}
Fetching photos in an album:
OQueryPhoto query = createQuery(Photo.class).filter(album, albumKey);
ListPhoto fetched = ofy.prepare(query).asList();
You can now move Photos between Albums easily and you can load/query
Albums efficiently.
-
GOOD IDEA #2:
I considered writing something about index entities as described here:
http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html
Re: [appengine-java] Presentation on doing full-text search etc
Wow. Thanks for Sharing. We start to get some juice out of GAE. After spending too much time on JPA then JDO, it is much easier and more efficient with http://code.google.com/p/objectify- appengine/wiki/IntroductionToObjectify#Multi-Value_Relationship Hope this may help some more since the GAE datastore is a completly different animal from the one(s) JPA and JDO are deseigned for. Duong BaTien DBGROUPS and BudhNet On Sun, 2010-01-24 at 06:04 -0800, Mats wrote: I though I'd share this presentation I found which includes some tips on using memcache, message delivery fanout, key only queries and a simple java version of this appengine-search http://www.billkatz.com/2009/6/Simple-Full-Text-Search-for-App-Engine Video part1: http://www.youtube.com/watch?v=wJuU-gME4dQ part2: http://www.youtube.com/watch?v=LSuFyBzPTlQ part3: http://www.youtube.com/watch?v=TOIR11EkNp8 Slides http://www.slideshare.net/sggtug/talk-1-google-app-engine-development-java-data-models-and-other-things-you-should-know-navin-kumar-cto-of-socialwokcom Example code http://searchguestbook.appspot.com/searchguestbook.tar.gz -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] How to use generated key.getId() to build parent child keys
Hi:
Has anyone figured out the use of generated long id in @PrinaryKey to
build a complete key graph. If not possible, what is the best technique
to generate long id for a complete graph of parent-child relationship.
Following is a use case:
UserOrg is the root entity with userId = f...@budhnet.com which
generate a 'message' sent to a list of receivers.
public class UserOrg {
@PrimaryKey private Key rootKey;
// the key is generated as
rootKey = KeyFactory.createdKey(UserOrg.class.getSimpleName(),
userId);
public class Message { //whose instance is generated by a userId
@PrimaryKey private Key messageKey;
// can the key be generated as one of the 2 followings
messageKey = new KeyFactory.Builder(UserOrg.class.getSimpleName(),
userId).addChild(Message.class.getSimpleName(), messageKey.getId
()).getKey();
or Key rootKey = KeyFactory.createKey(UserOrg.class.getSimpleName(),
userId);
messageKey = KeyFactory.createKey(rootKey, MessageClass.getSimpleName
(), rootKey.getChild().getId());
If not, what is the best practice in generating the long id for child
message of a userId. Same thing would apply for the MessageIndex of
receiver list.
public class MessageIndex { // child of the message created by userId
Key rootKey = KeyFactory.createKey(UserOrg.class.getSimpleName(),
userId);
messageKey = KeyFactory.createKey(rootKey, MessageClass.getSimpleName
(), rootKey.getChild().getId());
@PrimaryKey private Key messageIndexKey;
messageIndexKey = KeyFactory.createKey(messageKey,
MessageIndex.class.getSimpleName(), messageKey.getChild().getId());
The exercise is getting more complex for set intersection as shown in
python in
http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html
Has anyone worked out the Java code of the demos? the author?
Thanks
Duong BaTien
DBGROUPS and BudhNet
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Building Scalable Complex App
Hi Jason, the author Brett Slatkin and others: 1) For the list property, the video shows simple example of standard 1:n Message Receivers in python and Java. It then demonstrates a very efficient technique of Message and MessageIndex with the query of MessageIndex in python (NO Java from then on). I look at both the low level datastore with Query.setKeyOnly() and the query select id from to get the results of ListKey, then go through the loop to get the receivers. I may miss something, since the python code looks so clean. But once you are in any environment, it is very expensive to switch. This technique has major impact in data modeling. 2) Again for the set intersection, the python code looks so clean. I roughly sketch what need to be done on the Java side with either low level of datastore or with JDO. It is still not elegant as the shown codes. The demos are also in python. Again, the technique of merge join will have very significant impact on data modeling that GAE may surpass other platforms. Haven't put enough time in it yet, I wonder if any one has worked out the demos in Java and suggested best practices in data modeling for a complex large application. The job Brett Slatkin sets out to do has not completed without the Java codes since GAE now supports Java. Thanks Duong BaTien DBGROUPS and BudhNet On Tue, 2010-01-12 at 14:13 -0800, Jason (Google) wrote: Can you be more specific about what you're trying to accomplish so we don't have to search through the video to find what you're looking for? Or, at least provide a timeline reference that we can refer to in the video. :) Thanks, - Jason On Mon, Jan 11, 2010 at 7:29 AM, Duong BaTien duong.bat...@gmail.com wrote: Hi: Is there any blog and/or note to apply list properties and merge-join in python as in the following talk and demos http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html using Java and JDO? Thanks Duong BaTien DBGROUPS and BudhNet -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google- appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine- j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Building Scalable Complex App
Hi: Is there any blog and/or note to apply list properties and merge-join in python as in the following talk and demos http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html using Java and JDO? Thanks Duong BaTien DBGROUPS and BudhNet -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[google-appengine] WWW mapping for AppEngine
Hi: I messed up my www mapping in google apps for appengine. When dbgroups1.appspot.com of AppEngine mapped to http://www.dbgroups.com was directed to http://sites.google.com/a/dbgroups.com/www/ I try to solve the issue by: 1) deactivate the sites in google apps for dbgroups.com 2) deactivate, then permanently delete dbgroups1 under AppEngine I thought I can comeback to re-install dbgroups1 mapping from the scratch. This is not the case. The current status is: 1) In the AppEngine, i cannot access dbgroups1 anymore. 2) In dbgrous.com Apps, the services https://dbgroups1.appspot.com still mapping to http://www.dbgroups.com. I cannot delete it and the mapping still directed to sites. I understand that dbgroups1 id in appspot is still reserved and I have 1 extra application left due to the permanent deletion of dbgroups1. How can i get back to dbgroups1 and mapped to www.dbgroups.com It's my turn to have the issue. Thanks Duong BaTien DBGROUPS and BudhNet -- 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: WWW mapping for AppEngine
The problem is now solved by creating a new dbgroups3 and follow instructions in this post: http://www.google.com/support/forum/p/Google +Apps/thread?tid=66513228ad68b941hl=en On Mon, 2009-12-28 at 11:16 -0700, Duong BaTien wrote: Hi: I messed up my www mapping in google apps for appengine. When dbgroups1.appspot.com of AppEngine mapped to http://www.dbgroups.com was directed to http://sites.google.com/a/dbgroups.com/www/ I try to solve the issue by: 1) deactivate the sites in google apps for dbgroups.com 2) deactivate, then permanently delete dbgroups1 under AppEngine I thought I can comeback to re-install dbgroups1 mapping from the scratch. This is not the case. The current status is: 1) In the AppEngine, i cannot access dbgroups1 anymore. 2) In dbgrous.com Apps, the services https://dbgroups1.appspot.com still mapping to http://www.dbgroups.com. I cannot delete it and the mapping still directed to sites. I understand that dbgroups1 id in appspot is still reserved and I have 1 extra application left due to the permanent deletion of dbgroups1. How can i get back to dbgroups1 and mapped to www.dbgroups.com It's my turn to have the issue. Thanks Duong BaTien DBGROUPS and BudhNet -- 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.
Re: [google-appengine] www.winebythebar.com going to sites instead of appengine suddenly
Yes, it happened to many including my site aroud Dec 23. The solution is: (1) to deactive your site in google Apps. (2) deactivate, then permanently delete your site under GAE. Your app id at appspot.com is intact. It will take around 72 hours to completely delete your application in GAE. (3) re-map your application url and unload your application. Hope this may help. Duong BaTien DBGROUPS amd BudhNet On Sun, 2009-12-27 at 07:22 -0800, Thomas McKay - www.winebythebar.com wrote: I'm not sure where I should be asking for help for this. I've started a thread here: http://www.google.com/support/forum/p/Google+Apps/thread?tid=0b3a59520d9a980ehl=en My site, which has been working for over a year (and is both the server side of an Android app as well as my company website) has suddenly started redirecting www.winebythebar.com to http://sites.google.com/a/winebythebar.com/www/ . The likely start date is 26th Dec. Please help! My site, www.winebythebar.com, not being directed to sites instead of appengine suddenly T. McKay Level 1 9:52 AM Domain Name: http://www.winebythebar.com Edition: Affected Username/s: Issue Description: Visiting www.winebythebar.com now redirects to http://sites.google.com/a/winebythebar.com/www/ instead of hitting the appengine python. This site has been working for over a year (it is the server side of an Android app, besides being my company website). I have not changed any settings in cpanel in months. Any suggestions would be very welcome! Steps to Reproduce (if applicable): All replies T. McKay Level 1 9:54 AM Edit On cpanel I have two addresses mapped to my appengine app: www.winebythebar.com and incoming.winebythebar.com. incoming reaches the site correctly but www does not any more. Help! T. McKay Level 1 10:12 AM Edit Looking at this link http://groups.google.com/group/google-appengine/web/deleting-existing-www-mapping-from-google-apps but I don't have a mapping for www, only 'home' T. McKay Level 1 10:17 AM Edit In fact, trying to add 'www' as the above link describes in order to then delete it says that www is already in use. -- 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. -- 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: Reaching application limit
On Tue, 2009-11-10 at 13:17 -0800, Ikai L (Google) wrote: Richard, You should be able to create up to 20 applications now. I also want to note that SDK 1.2.6 made it possible to delete applications: http://code.google.com/appengine/kb/adminconsole.html#delete%5Fapp Thanks for pointing out this feature. Duong BaTien DBGROUPS and BudhNet On Tue, Nov 10, 2009 at 4:19 AM, Baron richar...@gmail.com wrote: thanks Nick On Nov 10, 10:57 pm, Baron richar...@gmail.com wrote: Hello, I have 9 applications used and am in discussion with another client, so I should soon reach 10. Could I please get more added to my quota? Thanks, Richard -- Ikai Lan Developer Programs Engineer, Google App Engine --~--~-~--~~~---~--~~ 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: Reaching 10 apps. Can someone at Google please help.
On Tue, 2009-09-15 at 15:53 +0100, Nick Johnson (Google) wrote: Hi observer, I've increased the number of apps you can create to 20. -Nick Johnson Thanks Google. Duong BaTien DBGROUPS and BudhNet On Mon, Sep 14, 2009 at 7:56 PM, observer247 prem...@gmail.com wrote: I like the app engine platform and have spent quite a lot of time to learn python and now I use app engine for most of the things I need to do on the web. I have already reached 9 apps and I have around 5 apps ready to be deployed. Can someone please increase the number of apps to 20. I have a billable account and I would like to work the legitimate way instead of trying to use others account etc. Thanks and will really appreciate this ! -- 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 -~--~~~~--~~--~--~---
[appengine-java] Re: SDK-1.2.5 for various GWT modules
I find out the issue. It is the cache in my browser of previous error. Please ignore the question. BaTien On Mon, 2009-09-14 at 10:18 -0600, Duong BaTien wrote: Hi: I use GAE SDK and GWT for different applications. For GAE SDK, i take out 3 libs related to jpa since i use jdo (datanucleus-jpa-1.1.5, geronima-jpa_3.0_spec-1.1.1, geronimo-jta_1.1_spec-1.1.1). For GWT modules, i do not use eclipse but use ant build: ant-1.7.0, jdk1.6, gwt- linux-1.7.0 All GWT modules, one built on top others through inherits , run as expeted for hosted, jar, javadoc. All GWT modules point to the same sdk- dir of appengine. After testing with runserver and update that module (dbgroups) to GAE, the runserver for other modules got the sticky of the previous successfully runserver (No file found for: /dbgroups/dbgroups.nocache.js) How can i change so one copy of SDK can be used for all GWT modules? Thanks Duong BaTien DBGROUPS and BudhNet --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: PLEASE HELP ME FIGHT GOOGLE SPAM
Hi Nick: I have similar, but business wide more serious, issue of forging the emails and send as spam to other web sides. I do not have time to investigate this issue yet since we are still converting everything to Google infrastructure using GAE and gmail, and will leverage Google Wave. Issue: We have 3 domain names. 1 domain name received a lot of spam mail and was forged to send spam mail to others many years ago. I converted my mail services for sending and receiving to gmail and moved the domain name to GoDaddy. The received and sending spam mails become less, but still there. The other 2 domain names are recent in the past 2-3 years using GoDaddy DNS and google mail services right from the beginning. Recently, some forged emails using the 3 domain names with different user names are sent to various sites. I configure gmail to received all mails under the domain names but not delivered to legitimate users to one account, and see the spam and undelivered mails to direct users to their web sites in Russia and China. The question are (1) How can they forge the domain name with their faked user names and send emails to spam others which will definitely damage our domain names? (2) What can i do to prevent this? In the near future, DNS and simple public web sites are only 2 things we use from GoDaddy; the web sites are used for publishing XML configurations for Google gadgets and for online backups of live services from google. Thanks BaTien DBGROUPS and BudhNet On Thu, 2009-07-09 at 10:26 +0100, Nick Johnson (Google) wrote: Hi Paul, On Tue, Jul 7, 2009 at 11:03 PM, Paul NOSPAMjelst...@netzero.com wrote: Hello, I have a yahoo e-mail account, where I am getting TONS of spam, that are advertising a website like this - http://caatainc1.appspot.com/ I traced the domain back to Google, and called them, because sending dozens of e-mails resulted in nothing happening. Guess what? Calling them does no good either!! I did get a little girl, who directed me to the APPSPOT.com site, where I could complain about the spam, but guess what? there is NO contact information for reporting this crap!! We have an abuse report form, here: http://code.google.com/support/bin/request.py?contact_type=AppEngineContact Note that simply being linked to in spam is not itself in violation of our terms of service - nobody can control who links to them - but it's possible this application is in violation of other parts of our TOS. So, if someone on this board could PLEASE let me know how I can stop these assholes, from continuing to SPAM me from their GOOGLE appspot, using their GMAIL account, I would GREATLY appreciate it. The emails are almost certainly not being sent from App Engine (which would _definitely_ be a violation of our TOS) or from gmail - they're simply linking to an App Engine app, and forging a gmail from address. Unfortunately, the real hosts of such spammers are usually the sort that are either offshore in some spam-friendly jurisdiction, or hosted by people who don't pay much attention to abuse reports. My own spam folder testifies to how prevalent this is. Regards, Nick Johnson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
