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 <andreas.borg...@gmail.com> 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 <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 <guillermo.schw...@gmail.com> > > > 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 <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 <guillermo.schw...@gmail.com> > > > > > wrote: > > > > > > > One question: Why didn't you consider jiql? > > > > > > > On Mon, Mar 29, 2010 at 1:04 PM, Blake <blakecaldw...@gmail.com> > > > wrote: > > > > > > > +1 > > > > > > > > On Mar 29, 4:03 am, Andreas Borglin <andreas.borg...@gmail.com> > > > 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<google-appengine-java%2B > > > > > > > unsubscr...@googlegroups.com><google-appengine-java%2B > > > 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 > > ... > > read more » -- 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.