[appengine-java] Re: Objectify - Twig - SimpleDS articles
+1 On Mar 29, 4:03 am, Andreas Borglin wrote: > Hi all. > > I recently decided to migrate away from JDO to one of the third party > datastore frameworks. At first I had only heard about objectify, but > after some further digging I found out about 5 other frameworks as > well (Twig, SimpleDS, siena, slim3, cloud2db). > > I was only interested in simple wrapper frameworks that acted as a > convenience layer above the AppEngine low-level API. I _want_ the > framework to expose the true nature of the datastore, but at the same > time relieve the developer of the tedious tasks that's involved when > working with the low-level API directly. It is much easier to work > with the AppEngine datastore when its concepts, features, constraints > and limitations are exposed directly. You can read more about the > reasons for this in the article. > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > are multi-platform and slim3 is more than just a datastore framework) > > I spent some time researching these when I got the idea to write an > article about them. I contacted the authors for each framework and > asked if they would be interested in participating. Passionate as they > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > The goal is to publish two articles; one interview with the authors, > and one where I solve some typical scenario with each framework. > The interview article has now been published and can be found > athttp://borglin.net/gwt-project/?page_id=604. > The code example article will be posted sometime in the upcoming two > weeks. -- 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: Objectify - Twig - SimpleDS articles
Hi Guillermo. Well, it's hard to consider things that I didn't know existed :-). I was only aware of the six frameworks that I mentioned in the post. I'll take a look at it. On 29 mar, 20:52, Guillermo Schwarz wrote: > One question: Why didn't you consider jiql? > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > > +1 > > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > > Hi all. > > > > I recently decided to migrate away from JDO to one of the third party > > > datastore frameworks. At first I had only heard about objectify, but > > > after some further digging I found out about 5 other frameworks as > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > I was only interested in simple wrapper frameworks that acted as a > > > convenience layer above the AppEngine low-level API. I _want_ the > > > framework to expose the true nature of the datastore, but at the same > > > time relieve the developer of the tedious tasks that's involved when > > > working with the low-level API directly. It is much easier to work > > > with the AppEngine datastore when its concepts, features, constraints > > > and limitations are exposed directly. You can read more about the > > > reasons for this in the article. > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > > are multi-platform and slim3 is more than just a datastore framework) > > > > I spent some time researching these when I got the idea to write an > > > article about them. I contacted the authors for each framework and > > > asked if they would be interested in participating. Passionate as they > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > The goal is to publish two articles; one interview with the authors, > > > and one where I solve some typical scenario with each framework. > > > The interview article has now been published and can be found athttp:// > > borglin.net/gwt-project/?page_id=604. > > > The code example article will be posted sometime in the upcoming two > > > weeks. > > > -- > > 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. > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect -- 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: Objectify - Twig - SimpleDS articles
Hi again. I had a look at jiql. "jiql is a JDBC wrapper for accessing Google DataStore on Google App Engine for JAVA. jiql supports the use of standard SQL as a method for accessing the DataStore" Even if I had seen jiql earlier I wouldn't have considered it anyway because, 1. I want the API to make perfect sense for working with the datastore. "Standard SQL" doesn't meet this requirement. 2. I use GWT. Not JSP or any other technology to dynamically generate pages on server side. On Mar 29, 8:52 pm, Guillermo Schwarz wrote: > One question: Why didn't you consider jiql? > > > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > > +1 > > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > > Hi all. > > > > I recently decided to migrate away from JDO to one of the third party > > > datastore frameworks. At first I had only heard about objectify, but > > > after some further digging I found out about 5 other frameworks as > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > I was only interested in simple wrapper frameworks that acted as a > > > convenience layer above the AppEngine low-level API. I _want_ the > > > framework to expose the true nature of the datastore, but at the same > > > time relieve the developer of the tedious tasks that's involved when > > > working with the low-level API directly. It is much easier to work > > > with the AppEngine datastore when its concepts, features, constraints > > > and limitations are exposed directly. You can read more about the > > > reasons for this in the article. > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > > are multi-platform and slim3 is more than just a datastore framework) > > > > I spent some time researching these when I got the idea to write an > > > article about them. I contacted the authors for each framework and > > > asked if they would be interested in participating. Passionate as they > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > The goal is to publish two articles; one interview with the authors, > > > and one where I solve some typical scenario with each framework. > > > The interview article has now been published and can be found athttp:// > > borglin.net/gwt-project/?page_id=604. > > > The code example article will be posted sometime in the upcoming two > > > weeks. > > > -- > > 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 > unsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en. > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect -- 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: Objectify - Twig - SimpleDS articles
Andreas, I don't get it. You can use JDO and Hibernate with SQL. Given that jiql has a Hibernate config file, I guess using Hibernate with jiql would be so easy. What does GWT and JSP have to do with SQL anyway? Cheers, Guillermo. On 30 mar, 03:51, Andreas Borglin wrote: > Hi again. > > I had a look at jiql. > "jiql is a JDBC wrapper for accessing Google DataStore on Google App > Engine for JAVA. > jiql supports the use of standard SQL as a method for accessing > the DataStore" > > Even if I had seen jiql earlier I wouldn't have considered it anyway > because, > > 1. I want the API to make perfect sense for working with the > datastore. "Standard SQL" doesn't meet this requirement. > 2. I use GWT. Not JSP or any other technology to dynamically generate > pages on server side. > > On Mar 29, 8:52 pm, Guillermo Schwarz > wrote: > > > One question: Why didn't you consider jiql? > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > > > +1 > > > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > > > Hi all. > > > > > I recently decided to migrate away from JDO to one of the third party > > > > datastore frameworks. At first I had only heard about objectify, but > > > > after some further digging I found out about 5 other frameworks as > > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > > I was only interested in simple wrapper frameworks that acted as a > > > > convenience layer above the AppEngine low-level API. I _want_ the > > > > framework to expose the true nature of the datastore, but at the same > > > > time relieve the developer of the tedious tasks that's involved when > > > > working with the low-level API directly. It is much easier to work > > > > with the AppEngine datastore when its concepts, features, constraints > > > > and limitations are exposed directly. You can read more about the > > > > reasons for this in the article. > > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > > > are multi-platform and slim3 is more than just a datastore framework) > > > > > I spent some time researching these when I got the idea to write an > > > > article about them. I contacted the authors for each framework and > > > > asked if they would be interested in participating. Passionate as they > > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > > The goal is to publish two articles; one interview with the authors, > > > > and one where I solve some typical scenario with each framework. > > > > The interview article has now been published and can be found athttp:// > > > borglin.net/gwt-project/?page_id=604. > > > > The code example article will be posted sometime in the upcoming two > > > > weeks. > > > > -- > > > 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 > > unsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > -- > > Saludos cordiales, > > > Guillermo Schwarz > > Sun Certified Enterprise Architect -- 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: Objectify - Twig - SimpleDS articles
Ok, you seem to misunderstand me quite a bit here. I never said it can't be used. I just said that I don't want to. Other than for portability reasons, why would I want to pretend that the datastore is relational by using a framework that emulates this? My main requirement, which was formed after using j...@gae, is that I want to use a framework that has a natural mapping to the datastore. I'm not saying that there is anything wrong with JDO/JPA, cloud2db or jiql in general. I'm just saying that, for me, it makes more sense to use a framework that exposes the true nature of the datastore (which is very different from a relational database), instead of hiding it under a portable abstraction layer. Simplicity and performance is more important than portability for me. That is of course not true for many other projects, so I'm only speaking from my perspective. If you can argue that jiql (or any other multi-platform framework like cloud2db, etc) can provide a natural mapping to the datastore AND be as efficient as the low-level wrappers, I'm all ears. j...@gae didn't do it for me at least. I never said that GWT had anything to do with SQL. I just don't want to use JDBC. On Mar 30, 3:51 pm, Guillermo Schwarz wrote: > Andreas, > > I don't get it. You can use JDO and Hibernate with SQL. Given that > jiql has a Hibernate config file, I guess using Hibernate with jiql > would be so easy. > > What does GWT and JSP have to do with SQL anyway? > > Cheers, > Guillermo. > > On 30 mar, 03:51, Andreas Borglin wrote: > > > > > Hi again. > > > I had a look at jiql. > > "jiql is a JDBC wrapper for accessing Google DataStore on Google App > > Engine for JAVA. > > jiql supports the use of standard SQL as a method for accessing > > the DataStore" > > > Even if I had seen jiql earlier I wouldn't have considered it anyway > > because, > > > 1. I want the API to make perfect sense for working with the > > datastore. "Standard SQL" doesn't meet this requirement. > > 2. I use GWT. Not JSP or any other technology to dynamically generate > > pages on server side. > > > On Mar 29, 8:52 pm, Guillermo Schwarz > > wrote: > > > > One question: Why didn't you consider jiql? > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > > > > +1 > > > > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > > > > Hi all. > > > > > > I recently decided to migrate away from JDO to one of the third party > > > > > datastore frameworks. At first I had only heard about objectify, but > > > > > after some further digging I found out about 5 other frameworks as > > > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > > > I was only interested in simple wrapper frameworks that acted as a > > > > > convenience layer above the AppEngine low-level API. I _want_ the > > > > > framework to expose the true nature of the datastore, but at the same > > > > > time relieve the developer of the tedious tasks that's involved when > > > > > working with the low-level API directly. It is much easier to work > > > > > with the AppEngine datastore when its concepts, features, constraints > > > > > and limitations are exposed directly. You can read more about the > > > > > reasons for this in the article. > > > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > > > > are multi-platform and slim3 is more than just a datastore framework) > > > > > > I spent some time researching these when I got the idea to write an > > > > > article about them. I contacted the authors for each framework and > > > > > asked if they would be interested in participating. Passionate as they > > > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > > > The goal is to publish two articles; one interview with the authors, > > > > > and one where I solve some typical scenario with each framework. > > > > > The interview article has now been published and can be found > > > > > athttp:// > > > > borglin.net/gwt-project/?page_id=604. > > > > > The code example article will be posted sometime in the upcoming two > > > > > weeks. > > > > > -- > > > > 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 > > > unsubscr...@googlegroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > > -- > > > Saludos cordiales, > > > > Guillermo Schwarz > > > Sun Certified Enterprise Architect -- 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
[appengine-java] Re: Objectify - Twig - SimpleDS articles
Thanks Nick :-). On Mar 30, 12:53 pm, "Nick Johnson (Google)" wrote: > Hi Andreas, > > Excellent article! I've posted it to the App Engine > reddit:http://www.reddit.com/r/AppEngine/comments/bk4kt/datastore_frameworks... > > Please feel free to post the followup article(s) there, too, to make sure > they get a wide distribution! > > -Nick Johnson > > On Mon, Mar 29, 2010 at 9:03 AM, Andreas Borglin > wrote: > > > > > > > Hi all. > > > I recently decided to migrate away from JDO to one of the third party > > datastore frameworks. At first I had only heard about objectify, but > > after some further digging I found out about 5 other frameworks as > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > I was only interested in simple wrapper frameworks that acted as a > > convenience layer above the AppEngine low-level API. I _want_ the > > framework to expose the true nature of the datastore, but at the same > > time relieve the developer of the tedious tasks that's involved when > > working with the low-level API directly. It is much easier to work > > with the AppEngine datastore when its concepts, features, constraints > > and limitations are exposed directly. You can read more about the > > reasons for this in the article. > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > are multi-platform and slim3 is more than just a datastore framework) > > > I spent some time researching these when I got the idea to write an > > article about them. I contacted the authors for each framework and > > asked if they would be interested in participating. Passionate as they > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > The goal is to publish two articles; one interview with the authors, > > and one where I solve some typical scenario with each framework. > > The interview article has now been published and can be found at > >http://borglin.net/gwt-project/?page_id=604. > > The code example article will be posted sometime in the upcoming two > > weeks. > > > -- > > 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 > unsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en. > > -- > 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 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: Objectify - Twig - SimpleDS articles
Hi Guillermo, > If you create a SQL interface on top of any of those, then it is a > relational database, not a fake but a real relational database. Why would I > want a relational database? Consistency, for starters. ACID transactions. > Set operations. 'Consistency' is a broad term. If you are implying 'foreign keys', GAE does not have any of these. If you mean 'consistency through ACID transactions', GAE requires entity groups. You are schemaless. Etc. You can create a SQL layer over the Datastore, but it will not be efficient or easy to debug. You can still use Hibernate over it, but I fail to see the purpose in that. > Working directly with aseembly code and bits may be what you prefer, but if > history is correct, computer science is about building abstractions. Good > abstractions. I agree that you can create the wrong tools for the job, but > that doesn't stop other people to investigate and innovate to create better > tools (better abstractions). "Building abstractions" sounds like the type of committee-driven job that created SOAP and J2EE :D > > BTW: You dont need to use JDBC directly when working with CloudDB or jiql. > You can always select Hibernate, JDO or even JPA. The advantage of using an > extra level of abstraction is that if later the DataStore changes or there > is a new alternative to the DataStore that is faster (but has a new API) all > you need to do is to reimplement SQL on top of it and voila: All your > applications have been ported effortlessly. That's the whole point of using > abstraction layers. You can also do that at the JPA level, if I understand correctly. I can see the value in a language for manipulating the datastore. It's just that I don't see SQL fulfilling that role. -- Nacho. -- 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: Objectify - Twig - SimpleDS articles
These misunderstandings :-). I wouldn't say that computer science is about building abstractions..perhaps software engineering. (Dijkstra would have said less kind words than me about that :-) ) Anyways, as much as I agree that abstractions are nice, have you actually used AppEngine with these frameworks? If so, you would probably have noticed the infamous cold start time issue. My application will be in the low-medium traffic range, so users will likely encounter JVM spinups regularly. There is no way I can get an acceptable startup time using ANY framework like Hibernate/Spring/etc as the situation is right now on GAE/J. I will probably even throw out Guice soon because it affects the startup time too much. Also, I can't say that comparing assembly language with the low-level frameworks is especially accurate. Unless you are talking about using the low-level API directly, which is not what I am talking about. I think you kind of dodged my "if you can argue" question completely by stating that SQL is all pretty and nice. I know what SQL is, how it can be used, etc, etc. I can honestly say that I haven't reviewed the jiql <-> datastore mapping in much detail, but I have a hard time seeing how it would make sense. One of the problems by using j...@gae is that you never get a real feeling for how the datastore actually operates, so you keep making incorrect assumptions on how things work and you end up throwing away days worth of work. This is mainly due to the fact that the datastore concepts and limitations don't really fit into the whole JDO way of working. This affects both simplicity and performance. This is where the low-level wrapper frameworks come into the picture. Since they are built with the datastore concepts and limitations in the foundation, there are few surprises and there are no performance penalties. I just don't understand how an SQL interface would do a better job than JDO at this. Most of your arguments seems to circle around portability, but like I said, that is not the highest priority for me. Unless the low-level framework guys give up on their frameworks altogether, the "if the datastore API changes" argument doesn't apply. I still use a layer between my application and the datastore, so I wouldn't need to modify my applications anyway. How do you implement all those fancy SQL features on top of a datastore that doesn't support them natively, without either causing lots of confusion OR having serious performance issues? How you do implement joins effectively, for example? Just to be clear, I completely agree with you on WHY it's a good idea in general to use a standardized API/framework/technology. But it's just doesn't make sense (to me) on AppEngine due to how the datastore operates and the performance issues. On Mar 30, 5:03 pm, Guillermo Schwarz wrote: > Andreas, > > I think there is more misunderstanding again. > > SQL can be run on top of a file system (fseek, read, write) or on top of a > persistent hashmap (datastore). > > If you create a SQL interface on top of any of those, then it is a > relational database, not a fake but a real relational database. Why would I > want a relational database? Consistency, for starters. ACID transactions. > Set operations. > > Read: > 1.http://www.buzzle.com/articles/advantages-of-relational-databases.html > 2.http://www.sunadal.co.uk/db.php > 3.http://www.euclideanspace.com/software/information/relational/index.htm > > Working directly with aseembly code and bits may be what you prefer, but if > history is correct, computer science is about building abstractions. Good > abstractions. I agree that you can create the wrong tools for the job, but > that doesn't stop other people to investigate and innovate to create better > tools (better abstractions). > > BTW: You dont need to use JDBC directly when working with CloudDB or jiql. > You can always select Hibernate, JDO or even JPA. The advantage of using an > extra level of abstraction is that if later the DataStore changes or there > is a new alternative to the DataStore that is faster (but has a new API) all > you need to do is to reimplement SQL on top of it and voila: All your > applications have been ported effortlessly. That's the whole point of using > abstraction layers. > > Cheers, > Guillermo. > > On Tue, Mar 30, 2010 at 10:49 AM, Andreas Borglin > > > > > > wrote: > > > Ok, you seem to misunderstand me quite a bit here. > > > I never said it can't be used. I just said that I don't want to. > > Other than for portability reasons, why would I want to pretend that > > the datastore is relational by using a framework that emulates this? > > > My main requirement, which was formed after using j...@gae, is that I > > want to use a framework that has a natural mapping to the datastore. > > > I'm not saying that there is anything wrong with JDO/JPA, cloud2db or > > jiql in general. I'm just saying that, for me, it makes more sense to > > use a framework that exposes the true na
[appengine-java] Re: Objectify - Twig - SimpleDS articles
Oops. A bit tired here. I wrote SQL in some places where I actually meant jiql/cloud2db. On Mar 30, 5:58 pm, Andreas Borglin wrote: > These misunderstandings :-). > > I wouldn't say that computer science is about building > abstractions..perhaps software engineering. (Dijkstra would have said > less kind words than me about that :-) ) > > Anyways, as much as I agree that abstractions are nice, have you > actually used AppEngine with these frameworks? > If so, you would probably have noticed the infamous cold start time > issue. My application will be in the low-medium traffic range, so > users will likely encounter JVM spinups regularly. > There is no way I can get an acceptable startup time using ANY > framework like Hibernate/Spring/etc as the situation is right now on > GAE/J. I will probably even throw out Guice soon because it affects > the startup time too much. > > Also, I can't say that comparing assembly language with the low-level > frameworks is especially accurate. Unless you are talking about using > the low-level API directly, which is not what I am talking about. > > I think you kind of dodged my "if you can argue" question completely > by stating that SQL is all pretty and nice. I know what SQL is, how it > can be used, etc, etc. > I can honestly say that I haven't reviewed the jiql <-> datastore > mapping in much detail, but I have a hard time seeing how it would > make sense. One of the problems by using j...@gae is that you never get > a real feeling for how the datastore actually operates, so you keep > making incorrect assumptions on how things work and you end up > throwing away days worth of work. This is mainly due to the fact that > the datastore concepts and limitations don't really fit into the whole > JDO way of working. This affects both simplicity and performance. This > is where the low-level wrapper frameworks come into the picture. Since > they are built with the datastore concepts and limitations in the > foundation, there are few surprises and there are no performance > penalties. > > I just don't understand how an SQL interface would do a better job > than JDO at this. Most of your arguments seems to circle around > portability, but like I said, that is not the highest priority for me. > Unless the low-level framework guys give up on their frameworks > altogether, the "if the datastore API changes" argument doesn't apply. > I still use a layer between my application and the datastore, so I > wouldn't need to modify my applications anyway. > > How do you implement all those fancy SQL features on top of a > datastore that doesn't support them natively, without either causing > lots of confusion OR having serious performance issues? > How you do implement joins effectively, for example? > > Just to be clear, I completely agree with you on WHY it's a good idea > in general to use a standardized API/framework/technology. But it's > just doesn't make sense (to me) on AppEngine due to how the datastore > operates and the performance issues. > > On Mar 30, 5:03 pm, Guillermo Schwarz > wrote: > > > > > Andreas, > > > I think there is more misunderstanding again. > > > SQL can be run on top of a file system (fseek, read, write) or on top of a > > persistent hashmap (datastore). > > > If you create a SQL interface on top of any of those, then it is a > > relational database, not a fake but a real relational database. Why would I > > want a relational database? Consistency, for starters. ACID transactions. > > Set operations. > > > Read: > > 1.http://www.buzzle.com/articles/advantages-of-relational-databases.html > > 2.http://www.sunadal.co.uk/db.php > > 3.http://www.euclideanspace.com/software/information/relational/index.htm > > > Working directly with aseembly code and bits may be what you prefer, but if > > history is correct, computer science is about building abstractions. Good > > abstractions. I agree that you can create the wrong tools for the job, but > > that doesn't stop other people to investigate and innovate to create better > > tools (better abstractions). > > > BTW: You dont need to use JDBC directly when working with CloudDB or jiql. > > You can always select Hibernate, JDO or even JPA. The advantage of using an > > extra level of abstraction is that if later the DataStore changes or there > > is a new alternative to the DataStore that is faster (but has a new API) all > > you need to do is to reimplement SQL on top of it and voila: All your > > applications have been ported effortlessly. That's the whole point of using > > abstraction layers. > > > Cheers, > > Guillermo. > > > On Tue, Mar 30, 2010 at 10:49 AM, Andreas Borglin > > > wrote: > > > > Ok, you seem to misunderstand me quite a bit here. > > > > I never said it can't be used. I just said that I don't want to. > > > Other than for portability reasons, why would I want to pretend that > > > the datastore is relational by using a framework that emulates this? > > > > My main requirement, which was forme
[appengine-java] Re: Objectify - Twig - SimpleDS articles
Andreas, first thanks for the article, it was hugely interesting and of course thanks to all who have given us some alternatives to argue about! A few themes seem to come out of this for me 1) Some people are just either happier with what they know (SQL/ RDBMS) - perfectly understandable and probably more productive initially at least, but if someone didn't move the goalposts now and then we would never get any innovative change. 2) Some just have to live with existing code and work with that. That's life I guess. 3) Others see the datastore as a component of a different way of working which overall has some major benefits - making the use of the datastore simple and efficient is just part of the equation. 4) Abstraction is all very well - but if the trade off is a lack of clarity or poor performance then it is in danger of being an objective for its own sake. I don't think anyone has mentioned the famous impedance mis-match between OOP and RDBMS. It seems to me that BigTable is a better match to OOP than an RDBMS is - although I found JDO a struggle. I have the luxury of developing a Java app from scratch, which of course is not the same for everyone. I did get JDO to work but it does feel like I am making life hard for myself by doing so. Now all I have to do is decide which of the alternatives to go for . On Mar 30, 7:33 pm, Jeff Schnitzer wrote: > On Tue, Mar 30, 2010 at 8:03 AM, Guillermo Schwarz > > wrote: > > > SQL can be run on top of a file system (fseek, read, write) or on top of a > > persistent hashmap (datastore). > > > If you create a SQL interface on top of any of those, then it is a > > relational database, not a fake but a real relational database. Why would I > > want a relational database? Consistency, for starters. ACID transactions. > > Set operations. > > ...except that you *can't* actually create a performant relational > database on top of appengine. > > Let's be realistic here. There is one reason and one reason only why > modern RDBMSes can perform at anything remotely like the speeds > necessary for web applications: > > * Lots and lots of RAM, enough to cache whole indexes. > > You don't have this in appengine. You get, at best, somewhere around > 110 megs. How fast do you think an RDBMS is going to perform on a > machine that has been lobotomized to 100 megs of RAM??? If you have > an antique computer from the 1990s you can find out. > > I have no doubt that you can create an RDBMS on top of the GAE > datastore. I also have no doubt that trying to tune a Hibernate app > to run at reasonable speeds will be a nightmare that I never want to > experience. > > 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 - Twig - SimpleDS articles
One question: Why didn't you consider jiql? On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > +1 > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > Hi all. > > > > I recently decided to migrate away from JDO to one of the third party > > datastore frameworks. At first I had only heard about objectify, but > > after some further digging I found out about 5 other frameworks as > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > I was only interested in simple wrapper frameworks that acted as a > > convenience layer above the AppEngine low-level API. I _want_ the > > framework to expose the true nature of the datastore, but at the same > > time relieve the developer of the tedious tasks that's involved when > > working with the low-level API directly. It is much easier to work > > with the AppEngine datastore when its concepts, features, constraints > > and limitations are exposed directly. You can read more about the > > reasons for this in the article. > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > are multi-platform and slim3 is more than just a datastore framework) > > > > I spent some time researching these when I got the idea to write an > > article about them. I contacted the authors for each framework and > > asked if they would be interested in participating. Passionate as they > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > The goal is to publish two articles; one interview with the authors, > > and one where I solve some typical scenario with each framework. > > The interview article has now been published and can be found athttp:// > borglin.net/gwt-project/?page_id=604. > > The code example article will be posted sometime in the upcoming two > > weeks. > > -- > 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. > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- 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 - Twig - SimpleDS articles
Hi, You can try Cloud2db also. Please see the website http://www.cloud2db.com. This works with any JDBC client tools/frameworks like Squirrel, PowerArchitect, Hibernate in a client/server mode. This also works on Google App Engine server with native JDBC driver. Thanks, Sandeep. On Tue, Mar 30, 2010 at 3:51 AM, Andreas Borglin wrote: > Hi again. > > I had a look at jiql. > "jiql is a JDBC wrapper for accessing Google DataStore on Google App > Engine for JAVA. > jiql supports the use of standard SQL as a method for accessing > the DataStore" > > Even if I had seen jiql earlier I wouldn't have considered it anyway > because, > > 1. I want the API to make perfect sense for working with the > datastore. "Standard SQL" doesn't meet this requirement. > 2. I use GWT. Not JSP or any other technology to dynamically generate > pages on server side. > > On Mar 29, 8:52 pm, Guillermo Schwarz > wrote: > > One question: Why didn't you consider jiql? > > > > > > > > > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: > > > +1 > > > > > On Mar 29, 4:03 am, Andreas Borglin wrote: > > > > Hi all. > > > > > > I recently decided to migrate away from JDO to one of the third party > > > > datastore frameworks. At first I had only heard about objectify, but > > > > after some further digging I found out about 5 other frameworks as > > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > > > I was only interested in simple wrapper frameworks that acted as a > > > > convenience layer above the AppEngine low-level API. I _want_ the > > > > framework to expose the true nature of the datastore, but at the same > > > > time relieve the developer of the tedious tasks that's involved when > > > > working with the low-level API directly. It is much easier to work > > > > with the AppEngine datastore when its concepts, features, constraints > > > > and limitations are exposed directly. You can read more about the > > > > reasons for this in the article. > > > > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db > > > > are multi-platform and slim3 is more than just a datastore framework) > > > > > > I spent some time researching these when I got the idea to write an > > > > article about them. I contacted the authors for each framework and > > > > asked if they would be interested in participating. Passionate as > they > > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John > > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. > > > > > > The goal is to publish two articles; one interview with the authors, > > > > and one where I solve some typical scenario with each framework. > > > > The interview article has now been published and can be found > athttp:// > > > borglin.net/gwt-project/?page_id=604. > > > > The code example article will be posted sometime in the upcoming two > > > > weeks. > > > > > -- > > > 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 unsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > > -- > > Saludos cordiales, > > > > Guillermo Schwarz > > Sun Certified Enterprise Architect > > -- > 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: Objectify - Twig - SimpleDS articles
Sandeep, Please read Andreas article (link is in the first post of this thread): "The interview article has now been published and can be found at http://borglin.net/gwt-project/?page_id=604 ." It would be nice if the article included CloudDB too. Cheers, Guillermo. On Tue, Mar 30, 2010 at 9:17 AM, Sandeep Sathaye wrote: > Hi, > > You can try Cloud2db also. Please see the website http://www.cloud2db.com. > This works with any JDBC client tools/frameworks like Squirrel, > PowerArchitect, Hibernate in a client/server mode. This also works on Google > App Engine server with native JDBC driver. > > Thanks, > > Sandeep. > > On Tue, Mar 30, 2010 at 3:51 AM, Andreas Borglin < > andreas.borg...@gmail.com> wrote: > >> Hi again. >> >> I had a look at jiql. >> "jiql is a JDBC wrapper for accessing Google DataStore on Google App >> Engine for JAVA. >> jiql supports the use of standard SQL as a method for accessing >> the DataStore" >> >> Even if I had seen jiql earlier I wouldn't have considered it anyway >> because, >> >> 1. I want the API to make perfect sense for working with the >> datastore. "Standard SQL" doesn't meet this requirement. >> 2. I use GWT. Not JSP or any other technology to dynamically generate >> pages on server side. >> >> On Mar 29, 8:52 pm, Guillermo Schwarz >> wrote: >> > One question: Why didn't you consider jiql? >> > >> > >> > >> > >> > >> > On Mon, Mar 29, 2010 at 1:04 PM, Blake wrote: >> > > +1 >> > >> > > On Mar 29, 4:03 am, Andreas Borglin >> wrote: >> > > > Hi all. >> > >> > > > I recently decided to migrate away from JDO to one of the third >> party >> > > > datastore frameworks. At first I had only heard about objectify, but >> > > > after some further digging I found out about 5 other frameworks as >> > > > well (Twig, SimpleDS, siena, slim3, cloud2db). >> > >> > > > I was only interested in simple wrapper frameworks that acted as a >> > > > convenience layer above the AppEngine low-level API. I _want_ the >> > > > framework to expose the true nature of the datastore, but at the >> same >> > > > time relieve the developer of the tedious tasks that's involved when >> > > > working with the low-level API directly. It is much easier to work >> > > > with the AppEngine datastore when its concepts, features, >> constraints >> > > > and limitations are exposed directly. You can read more about the >> > > > reasons for this in the article. >> > >> > > > This left me with objectify, Twig and SimpleDS. (siena and cloud2db >> > > > are multi-platform and slim3 is more than just a datastore >> framework) >> > >> > > > I spent some time researching these when I got the idea to write an >> > > > article about them. I contacted the authors for each framework and >> > > > asked if they would be interested in participating. Passionate as >> they >> > > > are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John >> > > > Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. >> > >> > > > The goal is to publish two articles; one interview with the authors, >> > > > and one where I solve some typical scenario with each framework. >> > > > The interview article has now been published and can be found >> athttp:// >> > > borglin.net/gwt-project/?page_id=604. >> > > > The code example article will be posted sometime in the upcoming two >> > > > weeks. >> > >> > > -- >> > > 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> unsubscr...@googlegroups.com> >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/google-appengine-java?hl=en. >> > >> > -- >> > Saludos cordiales, >> > >> > Guillermo Schwarz >> > Sun Certified Enterprise Architect >> >> -- >> 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. > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- 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
Re: [appengine-java] Re: Objectify - Twig - SimpleDS articles
Andreas, I think there is more misunderstanding again. SQL can be run on top of a file system (fseek, read, write) or on top of a persistent hashmap (datastore). If you create a SQL interface on top of any of those, then it is a relational database, not a fake but a real relational database. Why would I want a relational database? Consistency, for starters. ACID transactions. Set operations. Read: 1. http://www.buzzle.com/articles/advantages-of-relational-databases.html 2. http://www.sunadal.co.uk/db.php 3. http://www.euclideanspace.com/software/information/relational/index.htm Working directly with aseembly code and bits may be what you prefer, but if history is correct, computer science is about building abstractions. Good abstractions. I agree that you can create the wrong tools for the job, but that doesn't stop other people to investigate and innovate to create better tools (better abstractions). BTW: You dont need to use JDBC directly when working with CloudDB or jiql. You can always select Hibernate, JDO or even JPA. The advantage of using an extra level of abstraction is that if later the DataStore changes or there is a new alternative to the DataStore that is faster (but has a new API) all you need to do is to reimplement SQL on top of it and voila: All your applications have been ported effortlessly. That's the whole point of using abstraction layers. Cheers, Guillermo. On Tue, Mar 30, 2010 at 10:49 AM, Andreas Borglin wrote: > > Ok, you seem to misunderstand me quite a bit here. > > I never said it can't be used. I just said that I don't want to. > Other than for portability reasons, why would I want to pretend that > the datastore is relational by using a framework that emulates this? > > My main requirement, which was formed after using j...@gae, is that I > want to use a framework that has a natural mapping to the datastore. > > I'm not saying that there is anything wrong with JDO/JPA, cloud2db or > jiql in general. I'm just saying that, for me, it makes more sense to > use a framework that exposes the true nature of the datastore (which > is very different from a relational database), instead of hiding it > under a portable abstraction layer. Simplicity and performance is more > important than portability for me. That is of course not true for many > other projects, so I'm only speaking from my perspective. > > If you can argue that jiql (or any other multi-platform framework like > cloud2db, etc) can provide a natural mapping to the datastore AND be > as efficient as the low-level wrappers, I'm all ears. j...@gae didn't > do it for me at least. > > I never said that GWT had anything to do with SQL. I just don't want > to use JDBC. > > On Mar 30, 3:51 pm, Guillermo Schwarz > wrote: > > Andreas, > > > > I don't get it. You can use JDO and Hibernate with SQL. Given that > > jiql has a Hibernate config file, I guess using Hibernate with jiql > > would be so easy. > > > > What does GWT and JSP have to do with SQL anyway? > > > > Cheers, > > Guillermo. > > > > On 30 mar, 03:51, Andreas Borglin wrote: > > > > > > > > > Hi again. > > > > > I had a look at jiql. > > > "jiql is a JDBC wrapper for accessing Google DataStore on Google App > > > Engine for JAVA. > > > jiql supports the use of standard SQL as a method for accessing > > > the DataStore" > > > > > Even if I had seen jiql earlier I wouldn't have considered it anyway > > > because, > > > > > 1. I want the API to make perfect sense for working with the > > > datastore. "Standard SQL" doesn't meet this requirement. > > > 2. I use GWT. Not JSP or any other technology to dynamically generate > > > pages on server side. > > > > > On Mar 29, 8:52 pm, Guillermo Schwarz > > > wrote: > > > > > > One question: Why didn't you consider jiql? > > > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake > wrote: > > > > > +1 > > > > > > > On Mar 29, 4:03 am, Andreas Borglin > wrote: > > > > > > Hi all. > > > > > > > > I recently decided to migrate away from JDO to one of the third > party > > > > > > datastore frameworks. At first I had only heard about objectify, > but > > > > > > after some further digging I found out about 5 other frameworks > as > > > > > > well (Twig, SimpleDS, siena, slim3, cloud2db). > > > > > > > > I was only interested in simple wrapper frameworks that acted as > a > > > > > > convenience layer above the AppEngine low-level API. I _want_ the > > > > > > framework to expose the true nature of the datastore, but at the > same > > > > > > time relieve the developer of the tedious tasks that's involved > when > > > > > > working with the low-level API directly. It is much easier to > work > > > > > > with the AppEngine datastore when its concepts, features, > constraints > > > > > > and limitations are exposed directly. You can read more about the > > > > > > reasons for this in the article. > > > > > > > > This left me with objectify, Twig and SimpleDS. (siena and > cloud2db > > > > > > are multi-platform and slim3 is more tha
Re: [appengine-java] Re: Objectify - Twig - SimpleDS articles
Hi Guillermo, I agree with you completely. Here are my thoughts on the subject. Relational theory, SQL and JDBC are functional specifications and RDBMS vendors implement these specifications. Actually speaking data model has nothing to do with technology. A data model in software engineering is an abstract model that describes how data is represented and accessed. Data models formally define data elements and relationships among data elements for a domain of interest. The tools which extrapolate proper strategy for storing and accessing data on the underlying datastore based on the data model and expose it via SQL and JDBC in both client/server and server mode have a great advandage. This is our goal at Cloud2db. This abstraction layer also gives you complete flexibility of choosing your underlying datastore. For example, we are about to release Cloud2db Amazon SimpleDB and Hadoop Hbase implementations soon. Thanks, Sandeep. On Tue, Mar 30, 2010 at 11:03 AM, Guillermo Schwarz < guillermo.schw...@gmail.com> wrote: > Andreas, > > I think there is more misunderstanding again. > > SQL can be run on top of a file system (fseek, read, write) or on top of a > persistent hashmap (datastore). > > If you create a SQL interface on top of any of those, then it is a > relational database, not a fake but a real relational database. Why would I > want a relational database? Consistency, for starters. ACID transactions. > Set operations. > > Read: > 1. http://www.buzzle.com/articles/advantages-of-relational-databases.html > 2. http://www.sunadal.co.uk/db.php > 3. http://www.euclideanspace.com/software/information/relational/index.htm > > Working directly with aseembly code and bits may be what you prefer, but if > history is correct, computer science is about building abstractions. Good > abstractions. I agree that you can create the wrong tools for the job, but > that doesn't stop other people to investigate and innovate to create better > tools (better abstractions). > > BTW: You dont need to use JDBC directly when working with CloudDB or jiql. > You can always select Hibernate, JDO or even JPA. The advantage of using an > extra level of abstraction is that if later the DataStore changes or there > is a new alternative to the DataStore that is faster (but has a new API) all > you need to do is to reimplement SQL on top of it and voila: All your > applications have been ported effortlessly. That's the whole point of using > abstraction layers. > > Cheers, > Guillermo. > > > On Tue, Mar 30, 2010 at 10:49 AM, Andreas Borglin < > andreas.borg...@gmail.com> wrote: > >> >> Ok, you seem to misunderstand me quite a bit here. >> >> I never said it can't be used. I just said that I don't want to. >> Other than for portability reasons, why would I want to pretend that >> the datastore is relational by using a framework that emulates this? >> >> My main requirement, which was formed after using j...@gae, is that I >> want to use a framework that has a natural mapping to the datastore. >> >> I'm not saying that there is anything wrong with JDO/JPA, cloud2db or >> jiql in general. I'm just saying that, for me, it makes more sense to >> use a framework that exposes the true nature of the datastore (which >> is very different from a relational database), instead of hiding it >> under a portable abstraction layer. Simplicity and performance is more >> important than portability for me. That is of course not true for many >> other projects, so I'm only speaking from my perspective. >> >> If you can argue that jiql (or any other multi-platform framework like >> cloud2db, etc) can provide a natural mapping to the datastore AND be >> as efficient as the low-level wrappers, I'm all ears. j...@gae didn't >> do it for me at least. >> >> I never said that GWT had anything to do with SQL. I just don't want >> to use JDBC. >> >> On Mar 30, 3:51 pm, Guillermo Schwarz >> wrote: >> > Andreas, >> > >> > I don't get it. You can use JDO and Hibernate with SQL. Given that >> > jiql has a Hibernate config file, I guess using Hibernate with jiql >> > would be so easy. >> > >> > What does GWT and JSP have to do with SQL anyway? >> > >> > Cheers, >> > Guillermo. >> > >> > On 30 mar, 03:51, Andreas Borglin wrote: >> > >> > >> > >> > > Hi again. >> > >> > > I had a look at jiql. >> > > "jiql is a JDBC wrapper for accessing Google DataStore on Google App >> > > Engine for JAVA. >> > > jiql supports the use of standard SQL as a method for accessing >> > > the DataStore" >> > >> > > Even if I had seen jiql earlier I wouldn't have considered it anyway >> > > because, >> > >> > > 1. I want the API to make perfect sense for working with the >> > > datastore. "Standard SQL" doesn't meet this requirement. >> > > 2. I use GWT. Not JSP or any other technology to dynamically generate >> > > pages on server side. >> > >> > > On Mar 29, 8:52 pm, Guillermo Schwarz >> > > wrote: >> > >> > > > One question: Why didn't you consider jiql? >> > >> > > > On Mon, Mar 29
Re: [appengine-java] Re: Objectify - Twig - SimpleDS articles
First of all, please accept big thanks, Andreas. Those knowledge sharing is helpful to me as well as other learners. Follow the thread, I think I was a bit misled on benefit of SQL/JDBC on GAE. In Andreas blog's, he mentioned on learning curve to deal with the mapping: Java classess <--> JDO/JPA <- implementation specific to datastore -> Datastore That's why he looked for low-level wrapper frameworks. (do read his post first) Surprisingly, there're even suggestion to him: Java classes <--> JPA <-- Hibernate implementation --> 3rd party implementation (JDBC/SQL) <--> Datastore "Data models formally define data elements and relationships among data elements for a domain of interest." Yes, 100% agree. So, it is honestly speaking that "data model has nothing to do with technology"? What about is the big mismatch between model and physical storage? and purpose of object-relational mapping tool? More mappings and less mismatch? Reading Google GAE docs, forum, blog, as well as other non-Google site ( stackoverflow.com, highscalability.com ..) the stress is, datastore is not relational DB. What a coincidence! On Tue, Mar 30, 2010 at 10:47 PM, Sandeep Sathaye wrote: > Hi Guillermo, > > I agree with you completely. Here are my thoughts on the subject. > > Relational theory, SQL and JDBC are functional specifications and RDBMS > vendors implement these specifications. Actually speaking data model has > nothing to do with technology. A data model in software engineering is an > abstract model that describes how data is represented and accessed. Data > models formally define data elements and relationships among data elements > for a domain of interest. > > The tools which extrapolate proper strategy for storing and accessing data > on the underlying datastore based on the data model and expose it via SQL > and JDBC in both client/server and server mode have a great advandage. This > is our goal at Cloud2db. This abstraction layer also gives you complete > flexibility of choosing your underlying datastore. For example, we are about > to release Cloud2db Amazon SimpleDB and Hadoop Hbase implementations soon. > > Thanks, > > Sandeep. > On Tue, Mar 30, 2010 at 11:03 AM, Guillermo Schwarz < > guillermo.schw...@gmail.com> wrote: > >> Andreas, >> >> I think there is more misunderstanding again. >> >> SQL can be run on top of a file system (fseek, read, write) or on top of a >> persistent hashmap (datastore). >> >> If you create a SQL interface on top of any of those, then it is a >> relational database, not a fake but a real relational database. Why would I >> want a relational database? Consistency, for starters. ACID transactions. >> Set operations. >> >> Read: >> 1. http://www.buzzle.com/articles/advantages-of-relational-databases.html >> 2. http://www.sunadal.co.uk/db.php >> 3. >> http://www.euclideanspace.com/software/information/relational/index.htm >> >> Working directly with aseembly code and bits may be what you prefer, but >> if history is correct, computer science is about building abstractions. Good >> abstractions. I agree that you can create the wrong tools for the job, but >> that doesn't stop other people to investigate and innovate to create better >> tools (better abstractions). >> >> BTW: You dont need to use JDBC directly when working with CloudDB or jiql. >> You can always select Hibernate, JDO or even JPA. The advantage of using an >> extra level of abstraction is that if later the DataStore changes or there >> is a new alternative to the DataStore that is faster (but has a new API) all >> you need to do is to reimplement SQL on top of it and voila: All your >> applications have been ported effortlessly. That's the whole point of using >> abstraction layers. >> >> Cheers, >> Guillermo. >> >> >> On Tue, Mar 30, 2010 at 10:49 AM, Andreas Borglin < >> andreas.borg...@gmail.com> wrote: >> >>> >>> Ok, you seem to misunderstand me quite a bit here. >>> >>> I never said it can't be used. I just said that I don't want to. >>> Other than for portability reasons, why would I want to pretend that >>> the datastore is relational by using a framework that emulates this? >>> >>> My main requirement, which was formed after using j...@gae, is that I >>> want to use a framework that has a natural mapping to the datastore. >>> >>> I'm not saying that there is anything wrong with JDO/JPA, cloud2db or >>> jiql in general. I'm just saying that, for me, it makes more sense to >>> use a framework that exposes the true nature of the datastore (which >>> is very different from a relational database), instead of hiding it >>> under a portable abstraction layer. Simplicity and performance is more >>> important than portability for me. That is of course not true for many >>> other projects, so I'm only speaking from my perspective. >>> >>> If you can argue that jiql (or any other multi-platform framework like >>> cloud2db, etc) can provide a natural mapping to the datastore AND be >>> as efficient as the low-level wrapper
Re: [appengine-java] Re: Objectify - Twig - SimpleDS articles
On Tue, Mar 30, 2010 at 8:03 AM, Guillermo Schwarz wrote: > > SQL can be run on top of a file system (fseek, read, write) or on top of a > persistent hashmap (datastore). > > If you create a SQL interface on top of any of those, then it is a > relational database, not a fake but a real relational database. Why would I > want a relational database? Consistency, for starters. ACID transactions. > Set operations. ...except that you *can't* actually create a performant relational database on top of appengine. Let's be realistic here. There is one reason and one reason only why modern RDBMSes can perform at anything remotely like the speeds necessary for web applications: * Lots and lots of RAM, enough to cache whole indexes. You don't have this in appengine. You get, at best, somewhere around 110 megs. How fast do you think an RDBMS is going to perform on a machine that has been lobotomized to 100 megs of RAM??? If you have an antique computer from the 1990s you can find out. I have no doubt that you can create an RDBMS on top of the GAE datastore. I also have no doubt that trying to tune a Hibernate app to run at reasonable speeds will be a nightmare that I never want to experience. 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 - Twig - SimpleDS articles
i switch from JDO to Objectify i one Day. i changed 42 classes (thats what my svn says), but the key to success the migration was the tests: 57 green tests before start + 1 factibility test for objectify in transaction. Now my code is clean y work faster, NM On Tue, Mar 30, 2010 at 4:38 PM, David Sowerby wrote: > Andreas, first thanks for the article, it was hugely interesting and > of course thanks to all who have given us some alternatives to argue > about! A few themes seem to come out of this for me > > 1) Some people are just either happier with what they know (SQL/ > RDBMS) - perfectly understandable and probably more productive > initially at least, but if someone didn't move the goalposts now and > then we would never get any innovative change. > > 2) Some just have to live with existing code and work with that. > That's life I guess. > > 3) Others see the datastore as a component of a different way of > working which overall has some major benefits - making the use of the > datastore simple and efficient is just part of the equation. > > 4) Abstraction is all very well - but if the trade off is a lack of > clarity or poor performance then it is in danger of being an objective > for its own sake. > > I don't think anyone has mentioned the famous impedance mis-match > between OOP and RDBMS. It seems to me that BigTable is a better match > to OOP than an RDBMS is - although I found JDO a struggle. > > I have the luxury of developing a Java app from scratch, which of > course is not the same for everyone. I did get JDO to work but it > does feel like I am making life hard for myself by doing so. Now all > I have to do is decide which of the alternatives to go for . > > > On Mar 30, 7:33 pm, Jeff Schnitzer wrote: > > On Tue, Mar 30, 2010 at 8:03 AM, Guillermo Schwarz > > > > wrote: > > > > > SQL can be run on top of a file system (fseek, read, write) or on top > of a > > > persistent hashmap (datastore). > > > > > If you create a SQL interface on top of any of those, then it is a > > > relational database, not a fake but a real relational database. Why > would I > > > want a relational database? Consistency, for starters. ACID > transactions. > > > Set operations. > > > > ...except that you *can't* actually create a performant relational > > database on top of appengine. > > > > Let's be realistic here. There is one reason and one reason only why > > modern RDBMSes can perform at anything remotely like the speeds > > necessary for web applications: > > > > * Lots and lots of RAM, enough to cache whole indexes. > > > > You don't have this in appengine. You get, at best, somewhere around > > 110 megs. How fast do you think an RDBMS is going to perform on a > > machine that has been lobotomized to 100 megs of RAM??? If you have > > an antique computer from the 1990s you can find out. > > > > I have no doubt that you can create an RDBMS on top of the GAE > > datastore. I also have no doubt that trying to tune a Hibernate app > > to run at reasonable speeds will be a nightmare that I never want to > > experience. > > > > 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.
Re: [appengine-java] Re: Objectify - Twig - SimpleDS articles
On 31 Mar 2010, at 02:38, David Sowerby wrote: Now all I have to do is decide which of the alternatives to go for . Twig has the prettiest representative... however she has a very negative attitude towards traditional persistence interfaces on the datastore: http://code.google.com/p/twig-persist/#A_common_sentiment -- 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.
