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.

Reply via email to