Either way.
I was misremembering.
This is what I was thinking of:
http://groups.google.com/group/google-appengine-java/msg/d9dcf7b928beb4fb
From: Thomas Mueller <thomas.tom.muel....mail.com>
Date: Wed, 8 Apr 2009 13:52:27 -0700 (PDT)
Subject: Discussion on will-it-play-in-app-engine
Java Database Connectivity (JDBC): "Not supported" is technically not
correct. Better would be: "Not supported by Google". Reason: the APIs
are there, and using third-party in-memory databases such as the H2
Database Engine (which I write) or HSQLDB work. I plan to write an
open souce datastore to JDBC wrapper so that people can use the JDBC
API directly via frameworks that use the JDBC API.
On Fri, Apr 10, 2009 at 1:52 PM, Robert Zeigler
<robert.zeigle..mail.com> wrote:
> Reflection /is/ supported, with limitations.
> According to:
> http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox:
>
> Reflection
>
> An application is allowed full, unrestricted, reflective access to its own
> classes. It may query any private members, use
> java.lang.reflect.AccessibleObject.setAccessible(), and read/set private
> members.
>
> An application can also also reflect on JRE and API classes, such as
> java.lang.String and javax.servlet.http.HttpServletRequest. However, it can
> only access public members of these classes, not protected or private.
>
> An application cannot reflect against any other classes not belonging to
> itself, and it can not use the setAccessible() method to circumvent these
> restrictions.
>
> JDBC is not supported. The data store isn't based on a relational database;
> it's an object-oriented data store.
>
> From:
> http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
>
> "Java Database Connectivity (JDBC)
> Not supported - the App Engine datastore is not a relational store. Use JDO
> or JPA instead."
>
>
> That said, we could still /probably/ provide a db adapter for the app engine
> store, and instead of translating queries, etc. to sql, translate them to
> the appropriate api calls.
>
> I suppose, in theory, you could write a jdbc adapter that translates SQL to
> the appropriate api calls, but... that seems a little silly. :) The
> "dbadapter" approach is better, I think.
>
> Robert
>
> On Apr 10, 2009, at 4/1012:40 PM , Mike Kienenberger wrote:
>
>> From what I understand, it's not JDBC that's not supported, but the
>> lack of a Google Apps Engine JDBC driver.
>>
>> I haven't tried it, but it seems like it'd be easy enough set up.
>>
>> Yes, reflection isn't supported.
>>
>> Again, though, I think the real fitting point is not getting Cayenne
>> to run in entirety on the app engine as a java -> javascript
>> translated byte code, but to make sure that client-side ROP works on
>> the apps engine, with Cayenne running on the server-side.
>>
>> On Fri, Apr 10, 2009 at 10:47 AM, Andrus Adamchik
>> <andru..bjectstyle.org> wrote:
>>>
>>> On Apr 10, 2009, at 5:36 PM, Joseph Schmidt wrote:
>>>>
>>>> Can cayenne run on the new Google AppEngine/Java?
>>>>
>>>> I'm asking this because there are quite some restrictions to the
>>>> applications that work, and many known frameworks don't work (but the
>>>> authors promised to make them work - e.g. Tapestry):
>>>>
>>>>
>>>> http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine
>>>>
>>>> e.g. Hibernate does not work (maybe this might be the chance for Cayenne
>>>> to get some more publicity if it could work :) ?).
>>>>
>>>> thanks,
>>>> Joseph.
>>>
>>> A good question...
>>>
>>> IIRC Google apps engine does not support JDBC? So that will be a
>>> showstopper, although the stack is abstracted well enough so that it
>>> should
>>> be possible to re-implement a non-JDBC DataNode. Otherwise Cayenne does
>>> not
>>> rely on reflection for CayenneDataObjects, and should be possible to port
>>> ... I think.
>>>
>>>> maybe this might be the chance for Cayenne to get some more publicity if
>>>> it could work :) ?).
>>>
>>>
>>> This might also be a chance for new Cayenne volunteers to get publicity
>>> ;)
>>>
>>> Andrus
>>>
>
>
This archive was generated by hypermail 2.0.0 : Fri Apr 10 2009 - 14:01:17 EDT