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 > > 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> > > . > > 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.
