[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=feedburner&utm_medium=feed&utm_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=feedburner&utm_medium=feed&utm_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
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: 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: Manually restart GAE on the cloud
We increase the version number, load it up, test it, then change to the new version, delete the old one. BaTien DBGROUPS and BudhNet On Wed, 2010-04-28 at 11:15 +0700, Chau Huynh wrote: > Delete the version and redeploy, maybe? > Or should Google hep you look into your case, as App Engine user do > not have such direct control on their system to reboot. > > On Wed, Apr 28, 2010 at 10:54 AM, Phuong Nguyen > wrote: > I think disable/enable your app doesnot reboot JVM. > > I'm trying FreeMarker. If JVM process a class for the first > time, then > VerifyError is thrown. On second time, it throw > NoClassDefFoundError. > When I disabled and reenabled, JVM still throws > NoClassDefFoundError. > So I guess JVM is not restarted. > > On Apr 28, 10:00 am, Thomas wrote: > > In the Admin Console you can disable your application and > re-enable > > it. I think it is much like a JVM reboot. > > > > -- > > 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 > athttp://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. -- 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 wrote:
> >
> > On Apr 1, 3:14 am, Jeff Schnitzer 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:
>
> Iterable 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 ValueIf {
> 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
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)
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 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) > >> 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 m
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) > 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] 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 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 List 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,
> > List 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 List getMessagesSentToUserId(String userId) {
> > List 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 = (List) 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
> > > 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 List, 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 wi
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 OKey album;
>Set> 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:
>
> OQuery query =
> createQuery(PhotoIndex.class).filter("photos", photoKey);
> List> keys = ofy.prepareKeysOnly(query).asList();
> List 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 List> 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 OKey userKey;
List> messageKeys;
}
class Message {
@Id Long messageId;
String ccontent;
}
To query the list of users a particular messageKey is sent to:
OQuery query =
ObjectifyService.createQuery(MessageIndex.class).filter(messageKeys,
messageKey);
List> userKeys = ofy.prepareKeysOnly(query).asList();
List users = ofy.get(userKeys);
To query what messages are waiting for me:
OQuery query = ObjectifyService.createQuery
(MessageIndex.class).filter(userKey, meKey);
List> 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
> 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;
> List> 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:
>
> List 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 OKey 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:
>
> OQuery query = createQuery(Photo.class).ancestor(albumKey);
> List 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;
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.
Re: [appengine-java] Re: Objectify-Appengine, a typesafe data persistence tier for App Engine
Wow. Thanks. I will spend some time to explore this and will get back to you. Please explore the talk (where is the author's opinion? :-), especially the set intersections which to me very relevant to the complexity of social graphs. Please let the community know in real codes the contribution of the Objectify. The next step may be a REST service for GAE, leveraging existing services such as Restlet, rather than simple quick fixes. Duong BaTien DBGROUPS and BudhNet On Thu, 2010-01-21 at 12:43 -0800, Jeff Schnitzer wrote: > On Thu, Jan 21, 2010 at 7:48 AM, Duong BaTien wrote: > > > > While exploring list-property and merge-join from this talk > > http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html > > i concur with your value proposition. > > Neat, I had missed that talk. Good stuff. More comments inline: > > > Initially, i plan to build a singleton long id generator to reproduce > > and self-manage datastore Key of the application entity graph. Then use > > the low-level datastore to create list-property and merge-join: User -> > > Message -> MessageIndex or User -> Activity -> ActivityIndex (of > > different properties such as Interest, Checkout, MesurableEvent, etc). > > Please: > > 1) Explain the difference from objectify-appengine with this simple- > > mind approach in the immediate and long term project. > > There isn't much of a difference at all. Objectify is a *very* thin > wrapper around the low-level API. Generally speaking, you do > everything the same as the way you would do it with the low-level API > except you get to use your typed objects instead of Entity. > > Merge joins and list properties work exactly the same in Objectify as > they do in the low-level API. I'm not in a good position to evaluate > your specific problem domain, but I feel confident saying that if > you're considering the low-level API, you will be much happier using > Objectify. > > > 2) It is excellent to show an example of both list-property and merge- > > join as well as best practices to leverage the zig-zag search of the app > > engine. > > I wrote a little bit about list properties in the context of a > Multi-Value Relationship in this section: > > http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjectify#Multi-Value_Relationship > > But truly, there's nothing complicated about list properties in > Objectify. If you save a property of type List then it comes > back as List. That Google I/O video did a far better job of > explaining zig-zag merge sorts than I ever could. > > > 3) Configuration with appengine-java-sdk if there is any significant > > change beside a small jar from objectify-appengine. > > Just add objectify-1.x.jar to your project and make sure that you > register your entities in your code (see > http://code.google.com/p/objectify-appengine/wiki/BestPractices). > That's it. > > 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] Re: Objectify-Appengine, a typesafe data persistence tier for App Engine
Hi:
While exploring list-property and merge-join from this talk
http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html
i concur with your value proposition.
Initially, i plan to build a singleton long id generator to reproduce
and self-manage datastore Key of the application entity graph. Then use
the low-level datastore to create list-property and merge-join: User ->
Message -> MessageIndex or User -> Activity -> ActivityIndex (of
different properties such as Interest, Checkout, MesurableEvent, etc).
Please:
1) Explain the difference from objectify-appengine with this simple-
mind approach in the immediate and long term project.
2) It is excellent to show an example of both list-property and merge-
join as well as best practices to leverage the zig-zag search of the app
engine.
3) Configuration with appengine-java-sdk if there is any significant
change beside a small jar from objectify-appengine.
Thanks
Duong BaTien
DGBROUPS and BudhNet
On Wed, 2010-01-20 at 23:45 -0800, Marcel Overdijk wrote:
> This really looks great!
>
> On 13 jan, 18:28, Jeff Schnitzer wrote:
> > http://code.google.com/p/objectify-appengine/
> >
> > I probably should have called this project "Goldilocks", because it's
> > a little bit how I feel. Despite being a longtime Hibernate user
> > (since the 1.0 days), the JDO/JPA abstraction just doesn't make me
> > happy on appengine - it's too big, too complicated, and too far
> > removed from the nature of the beast. The low-level API has an
> > elegant simplicity, but it lacks type safety. I tried the
> > alternatives - Siena, Twig, SimpleDS, and Slim3. There are good
> > things I can say about these projects but none were "just right" for
> > me.
> >
> > So, in time-honored tradition, I wrote my own and now I'm offering it
> > to the world. Here is what "just right" means to me. Maybe it's just
> > right for you too:
> >
> > * An interface that reflects the four fundamental datastore
> > operations - get, put, delete, query - including their batch variants.
> >
> > * Persisting real typed POJO classes - no detaching, no lifecycle,
> > serialize at will.
> >
> > * Keys inObjectifyare generified and typed. Instead of Key you use
> > OKey. This generic typing extends to OQuery and
> > OPreparedQuery.
> >
> > * Because Kind ~= POJO Class, Key should not be used for an object's
> > id. The object's id and its (optional) parent plus the class is
> > complete; an entity that has a Key identifier contains a redundant
> > (and potentially inaccurate) kind. Nevertheless, a Key is necessary
> > for loading entities or referencing entities, and forms a fundamental
> > part of the API. This dichotomy is something I don't feel had been
> > done right yet.
> >
> > * Queries are modeled after the human-friendly GAE/Python Query
> > class: query.filter("field >", 123).sort("-field"). You can filter
> > and sort on id fields almost as if they are normal properties.
> >
> > * Transactional behavior is contained within theObjectifyinterface
> > (analogous to DatastoreService) instance rather than a thread local.
> > You can easily have several transactions (or nontransactional
> > sessions) running concurrently.
> >
> > * You can use your entities in GWT-RPC without modification - even
> > with OKey fields. They're just POJOs and they serialize fine.
> >
> > * Builtin facilities to help with renaming fields and transforming
> > data during schema migration.
> >
> > * Configurable automatic retries for DatastoreTimeoutExceptions
> > (finally get rid of the 0.1% trickle of failures!).
> >
> > * Zero external dependencies - no Spring, no Guice, not even a logger
> > (it just wasn't necessary). Just one lonely 36K jar.
> >
> > *Objectifywill work nicely with your DI framework. Static
> > singletons are not required.
> >
> > * Negligible impact on cold start time.
> >
> > * Thorough unit test suite.
> >
> > * Simple, easy-to-read, well-documented code. Not counting the
> > tests, there's actually only ten source files plus three annotations.
> > About 2,000 lines including whitespace and javadocs.
> >
> > There is ample documentation
> > athttp://code.google.com/p/objectify-appengine/, but some code examples
> > should make this clear:
> >
> > Basic operations:
> >
> > @Entity
> > class Car {
> >@Id String vin; // Can be Long, long, or String
> >String co
[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:
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 List 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,
List 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 List getMessagesSentToUserId(String userId) {
List 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 = (List) 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
> 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 List, 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
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 List, 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 > 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.
[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 , 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 -~--~~~~--~~--~--~---
[appengine-java] Re: SDK-1.2.5 for various GWT modules
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 , 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 -~--~~~~--~~--~--~---
