Re: [appengine-java] Re: datanucleus-appengine

2010-12-21 Thread Cesar Ruiz
Can you please help me on my topic.

http://code.google.com/appengine/forum/java-forum.html?place=topic%2Fgoogle-appengine-java%2FCrftYtwWXgw%2Fdiscussion

On 16 December 2010 18:20, George Moschovitis
wrote:

> started a new app. For me, Objectify made Java persistence coding fun
>> again, and words like "persistence manager lifecycle" and "detached
>> instance" are blissfully draining out of my vocabulary :-)
>
>
> you may have a point here ;-)
>
> -g.
>
> --
> 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.
>



-- 
Cesar Ruiz.

-- 
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: datanucleus-appengine

2010-12-16 Thread George Moschovitis

>
> started a new app. For me, Objectify made Java persistence coding fun 
> again, and words like "persistence manager lifecycle" and "detached 
> instance" are blissfully draining out of my vocabulary :-) 


you may have a point here ;-)

-g. 

-- 
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: datanucleus-appengine

2010-12-06 Thread David Chandler
I don't know the back story on ROO-1797, but the issue report is, I
think, not entirely accurate. The Expenses sample app that shipped
with Roo 1.1 and GWT 2.1.0 runs on App Engine with DataNucleus.

Given that Spring Roo seems oriented towards RDBMSs, it would not
surprise me if there were a lot of one-off code in Roo to support App
Engine's non-relational aspects. However, the Spring team demoed the
standard travel booking app running on App Engine with hosted SQL
(http://code.google.com/appengine/business/#features) at SpringOne in
October, so I don't think cloud portability is exactly a lost cause.

Even if it is, I'll take the simplicity and scalability of the
Datastore vs. the portability of an API for which required me to
consult a 408-page (and later, 841-page) reference manual every time I
started a new app. For me, Objectify made Java persistence coding fun
again, and words like "persistence manager lifecycle" and "detached
instance" are blissfully draining out of my vocabulary :-)

/dmc
http://turbomanage.wordpress.com

On Dec 5, 3:41 am, George  Moschovitis 
wrote:
> On Dec 4, 6:56 am, John Howe  wrote:
>
> > Is that another "wave" I see on the horizon ...
>
> the news on the cloud-portability front are disappointing too:
>
> https://jira.springsource.org/browse/ROO-1797
>
> Remove support for DataNucleus 1.x and Google App Engine
>
> Since none of Roo's sample apps can deploy to the app engine and given
> there are a lot of hacks in the Roo code to allow even the simplest of
> apps to run in the app engine, this task is to remove all the code
> that supports the app engine until full SQL support is available. This
> also has the added benefit of being able to drop support for JPA 1.0
> with the removal of DataNuclueus 1.x
>
> maybe another reason to update datanuclues-appengine to datanucleus
> 2.x ?
>
> -g.

-- 
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: datanucleus-appengine

2010-12-06 Thread Jeff Schnitzer
On Fri, Dec 3, 2010 at 12:50 PM, George  Moschovitis
 wrote:
> - Objectify seems to have more momentum, but is not standard, dunno if
> this will be supported in a year or two

Just to give you a little perspective, it's worth pointing out how
thin projects like Objectify really are:

http://www.ohloh.net/p/objectify-appengine/analyses/latest

At less than 10k lines of code, compare this to Datanucleus (> 500k):

http://www.ohloh.net/p/datanucleus/analyses/latest

As the lead developer, I'm genuinely flattered that people hold
Objectify in such high regard, but I really have to give the credit to
the folks at Google working on the backend and the Low-Level API.
Objectify is a very simple project and we're trying to keep it that
way.  If I were to be hit by a bus tomorrow, there are plenty of other
people who can step up... or anyone using the code could branch/fork
it.  It's just not that complicated.

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.



[appengine-java] Re: datanucleus-appengine

2010-12-05 Thread Ian Marshall
I am encouraged by the contributions from Ikai and Max.

I forgot to mention in my earlier post one reason I elected to use JDO
as my interface to the datastore: to maintain the capability to port
my application to another hosting service without too much work.

That being said, I have no intention currently of porting away from
GAE/J. Despite various problems, I think that this is an excellent
offering which improves continuously. A big thank you to everyone who
is responsible!


On Dec 5, 8:41 am, George  Moschovitis 
wrote:
> On Dec 4, 6:56 am, John Howe  wrote:
>
> > Is that another "wave" I see on the horizon ...
>
> the news on the cloud-portability front are disappointing too:
>
> https://jira.springsource.org/browse/ROO-1797
>
> Remove support for DataNucleus 1.x and Google App Engine
>
> Since none of Roo's sample apps can deploy to the app engine and given
> there are a lot of hacks in the Roo code to allow even the simplest of
> apps to run in the app engine, this task is to remove all the code
> that supports the app engine until full SQL support is available. This
> also has the added benefit of being able to drop support for JPA 1.0
> with the removal of DataNuclueus 1.x
>
> maybe another reason to update datanuclues-appengine to datanucleus
> 2.x ?
>
> -g.

-- 
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: datanucleus-appengine

2010-12-05 Thread George Moschovitis

On Dec 4, 6:56 am, John Howe  wrote:
> Is that another "wave" I see on the horizon ...

the news on the cloud-portability front are disappointing too:

https://jira.springsource.org/browse/ROO-1797

Remove support for DataNucleus 1.x and Google App Engine

Since none of Roo's sample apps can deploy to the app engine and given
there are a lot of hacks in the Roo code to allow even the simplest of
apps to run in the app engine, this task is to remove all the code
that supports the app engine until full SQL support is available. This
also has the added benefit of being able to drop support for JPA 1.0
with the removal of DataNuclueus 1.x

maybe another reason to update datanuclues-appengine to datanucleus
2.x ?

-g.

-- 
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: datanucleus-appengine

2010-12-04 Thread George Moschovitis
> We are making sure it is keeping pace with our new SDK
> releases, and we hope to be able to start enhancing it as soon as we can.

let's hope this will be 'soon'.

> (did you see the mention of the "High Replication Datastore" in our latest
> blog 
> post
> ?)

not exactly sure what the "High Replication Datastore" is, but it
sounds promising...

-g.

-- 
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: datanucleus-appengine

2010-12-03 Thread John Howe
Is that another "wave" I see on the horizon ...

On Fri, Dec 3, 2010 at 1:01 PM, Ikai Lan (Google)

> wrote:

> That's a problem of your own creation. A multitude of choice is one of the
> benefits of any Java platform. For instance, you mention that Objectify
> seems great but may not be supported 1-2 years down the line. This is an
> argument that you can apply to just about any open source library or
> framework in existence. Even paid tools, for instance, can be deprecated.
> You're eager optimizing your support problem, when really the problem you
> should be solving is "what do I need to build? How do I get there?"
>
> In a previous life, I made the mistake of worrying about this with regards
> to using jQuery (silly, right?) and the Google Charts API. Instead, I built
> what is quite possibly one of the worst Javascript frameworks ever, and the
> project shipped late. I should have focused on the project, not phantom
> concerns about ongoing support for open source code.
>
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger: http://googleappengine.blogspot.com
> Reddit: http://www.reddit.com/r/appengine
> Twitter: http://twitter.com/app_engine
>
>
>
> On Fri, Dec 3, 2010 at 12:50 PM, George Moschovitis <
> george.moschovi...@gmail.com> wrote:
>
>> It 's counter productive for me, for the simple reason that I cannot
>> choose which API to
>> use:
>>
>> - JPA seems to be the standard but it's geared towards RDBMS
>> - JDO is 'older' but better supports non relational DBs
>> - Both of the above seem abandoned (for example they use a very old
>> Datanucleus version)
>> - the Low level is too ..low level with no support of static typing
>> (one of the benefits of using Java)
>> - Twig has interesting features but seems to lack momentum
>> - Objectify seems to have more momentum, but is not standard, dunno if
>> this will be supported in a year or two
>> - etc, etc..."
>>
>> As you can see I am on a deadlock, I cannot decide which API to use
>> and frankly all of the available options leave a lot
>> to be desired.
>>
>> New features like (Channel API, Reserved instances, etc) may be cool,
>> but really GAE/J needs a solid, dependable database story...
>>
>> just my 2 cents...
>> -g.
>>
>>
>> On Dec 3, 8:46 pm, "Ikai Lan (Google)" 
>> 
>> >
>> wrote:
>> > We'll investigate ways to keep JDO/JPA up to date.
>> >
>> > I disagree about the fact that having community driven libraries is
>> counter
>> > productive. In fact, this is a sign of a thriving community. When
>> evaluating
>> > our support of these libraries, we realized that we could have done a
>> better
>> > job helping the folks building great tools for App Engine users. We've
>> taken
>> > steps to better involve framework and library developers, and going
>> forward,
>> > we will be having higher expectations for our own involvement helping
>> these
>> > developers be successful.
>> >
>> > --
>> > Ikai Lan
>> > Developer Programs Engineer, Google App Engine
>> > Blogger:http://googleappengine.blogspot.com
>> > Reddit:http://www.reddit.com/r/appengine
>> > Twitter:http://twitter.com/app_engine
>> >
>> > On Fri, Dec 3, 2010 at 10:37 AM, George Moschovitis <
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > george.moschovi...@gmail.com> wrote:
>> > > > We haven't abandoned JDO/JPA, but we may emphasize the low-level
>> APIs
>> > > going
>> > > > forward. You'll always get low-level features first. The mismatch
>> between
>> > > > datastore features and relational database features is starting to
>> really
>> > > > grow.
>> >
>> > > I understand that emphasizing on the Low Level API makes sense, but
>> > > some work on JDO/JPA would be reasonable.
>> > > There is a lot of stuff that could be implemented on top of the
>> > > standard APIs.
>> >
>> > > Moreover, you could consider offering a custom Higher Level API, maybe
>> > > something similar to the Python version.
>> > > Having 10 slightly different community driven APIs is not productive.
>> >
>> > > regards,
>> > > -g.
>> >
>> > > > One thing we'll plan on doing is to work more closely with framework
>> and
>> > > > library implementors to make sure they have what they need to build
>> > > toolkits
>> > > > that better mesh with non-relational datastores. For instance, take
>> a
>> > > look
>> > > > at our recent article about Django:
>> >
>> > > >http://code.google.com/appengine/articles/django-nonrel.html
>> >
>> > > > (BTW, if you are a Python developer, please do not use
>> app-engine-patch.
>> > > > It's deprecated).
>> >
>> > > > The original approach we took and encouraged was to bend existing
>> > > toolkits
>> > > > to work with GAE to adhere to standards. We'll still do this when
>> > > possible,
>> > > > but we're more pragmatic than dogmatic about standards. In some
>> cases,
>> > > such
>> > > > as the datastore, it may make more sense for us to help developers
>> build
>> > > > toolkits that can keep up with the trend of non-relational
>> persistence.
>> >
>> > > > --

Re: [appengine-java] Re: datanucleus-appengine

2010-12-03 Thread Max Ross (Google)
There's a big difference between something that is deprecated and something
that isn't getting any new features.  JDO/JPA is most certainly not
deprecated.  We are making sure it is keeping pace with our new SDK
releases, and we hope to be able to start enhancing it as soon as we can.
 There is still a lot of good and important work to be done on this library,
but the App Engine team always prioritizes the reliability and availability
of our product over feature-related work, and as of late, those of us
working on the Datastore have been almost entirely focused on the former
(did you see the mention of the "High Replication Datastore" in our latest
blog 
post
?)

Finally, I'll point out that our DataNucleus plugin is completely open
source.  If you or anyone else in the community would like to submit a patch
with thorough test cases we will be happy to work with you to get it
submitted.

Thanks,
Max

On Fri, Dec 3, 2010 at 1:32 PM, George Moschovitis <
george.moschovi...@gmail.com> wrote:

> > You're eager optimizing your support problem, when really the problem you
> > should be solving is "what do I need to build? How do I get there?"
>
> I know what I want to build. My problem is that I (obviously) need a
> Datastore API. In the Google App Engine documentation
> the endorsed API was (until now) JDO (and maybe JPA).
>
> From your earlier post I learned  that JDO/JPA support is ..kind of
> deprecated.
>
> I don't plan to create a new API myself. I would prefer to use a
> Google-endorsed API, but today there is no such thing.
> I find this annoying. I may be wrong, but this is my perspective, we
> can't all agree on everything. Still, you should keep developer
> concerns
> in mind when laying out the road map for future releases.
>
> regards,
> -g.
>
>
> PS: and yes, I 'll probably use Objectify after all...
>
> --
> 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.



[appengine-java] Re: datanucleus-appengine

2010-12-03 Thread George Moschovitis
> You're eager optimizing your support problem, when really the problem you
> should be solving is "what do I need to build? How do I get there?"

I know what I want to build. My problem is that I (obviously) need a
Datastore API. In the Google App Engine documentation
the endorsed API was (until now) JDO (and maybe JPA).

>From your earlier post I learned  that JDO/JPA support is ..kind of
deprecated.

I don't plan to create a new API myself. I would prefer to use a
Google-endorsed API, but today there is no such thing.
I find this annoying. I may be wrong, but this is my perspective, we
can't all agree on everything. Still, you should keep developer
concerns
in mind when laying out the road map for future releases.

regards,
-g.


PS: and yes, I 'll probably use Objectify after all...

-- 
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: datanucleus-appengine

2010-12-03 Thread Ikai Lan (Google)
That's a problem of your own creation. A multitude of choice is one of the
benefits of any Java platform. For instance, you mention that Objectify
seems great but may not be supported 1-2 years down the line. This is an
argument that you can apply to just about any open source library or
framework in existence. Even paid tools, for instance, can be deprecated.
You're eager optimizing your support problem, when really the problem you
should be solving is "what do I need to build? How do I get there?"

In a previous life, I made the mistake of worrying about this with regards
to using jQuery (silly, right?) and the Google Charts API. Instead, I built
what is quite possibly one of the worst Javascript frameworks ever, and the
project shipped late. I should have focused on the project, not phantom
concerns about ongoing support for open source code.

--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blogger: http://googleappengine.blogspot.com
Reddit: http://www.reddit.com/r/appengine
Twitter: http://twitter.com/app_engine



On Fri, Dec 3, 2010 at 12:50 PM, George Moschovitis <
george.moschovi...@gmail.com> wrote:

> It 's counter productive for me, for the simple reason that I cannot
> choose which API to
> use:
>
> - JPA seems to be the standard but it's geared towards RDBMS
> - JDO is 'older' but better supports non relational DBs
> - Both of the above seem abandoned (for example they use a very old
> Datanucleus version)
> - the Low level is too ..low level with no support of static typing
> (one of the benefits of using Java)
> - Twig has interesting features but seems to lack momentum
> - Objectify seems to have more momentum, but is not standard, dunno if
> this will be supported in a year or two
> - etc, etc..."
>
> As you can see I am on a deadlock, I cannot decide which API to use
> and frankly all of the available options leave a lot
> to be desired.
>
> New features like (Channel API, Reserved instances, etc) may be cool,
> but really GAE/J needs a solid, dependable database story...
>
> just my 2 cents...
> -g.
>
>
> On Dec 3, 8:46 pm, "Ikai Lan (Google)" 
> 
> >
> wrote:
> > We'll investigate ways to keep JDO/JPA up to date.
> >
> > I disagree about the fact that having community driven libraries is
> counter
> > productive. In fact, this is a sign of a thriving community. When
> evaluating
> > our support of these libraries, we realized that we could have done a
> better
> > job helping the folks building great tools for App Engine users. We've
> taken
> > steps to better involve framework and library developers, and going
> forward,
> > we will be having higher expectations for our own involvement helping
> these
> > developers be successful.
> >
> > --
> > Ikai Lan
> > Developer Programs Engineer, Google App Engine
> > Blogger:http://googleappengine.blogspot.com
> > Reddit:http://www.reddit.com/r/appengine
> > Twitter:http://twitter.com/app_engine
> >
> > On Fri, Dec 3, 2010 at 10:37 AM, George Moschovitis <
> >
> >
> >
> >
> >
> >
> >
> > george.moschovi...@gmail.com> wrote:
> > > > We haven't abandoned JDO/JPA, but we may emphasize the low-level APIs
> > > going
> > > > forward. You'll always get low-level features first. The mismatch
> between
> > > > datastore features and relational database features is starting to
> really
> > > > grow.
> >
> > > I understand that emphasizing on the Low Level API makes sense, but
> > > some work on JDO/JPA would be reasonable.
> > > There is a lot of stuff that could be implemented on top of the
> > > standard APIs.
> >
> > > Moreover, you could consider offering a custom Higher Level API, maybe
> > > something similar to the Python version.
> > > Having 10 slightly different community driven APIs is not productive.
> >
> > > regards,
> > > -g.
> >
> > > > One thing we'll plan on doing is to work more closely with framework
> and
> > > > library implementors to make sure they have what they need to build
> > > toolkits
> > > > that better mesh with non-relational datastores. For instance, take a
> > > look
> > > > at our recent article about Django:
> >
> > > >http://code.google.com/appengine/articles/django-nonrel.html
> >
> > > > (BTW, if you are a Python developer, please do not use
> app-engine-patch.
> > > > It's deprecated).
> >
> > > > The original approach we took and encouraged was to bend existing
> > > toolkits
> > > > to work with GAE to adhere to standards. We'll still do this when
> > > possible,
> > > > but we're more pragmatic than dogmatic about standards. In some
> cases,
> > > such
> > > > as the datastore, it may make more sense for us to help developers
> build
> > > > toolkits that can keep up with the trend of non-relational
> persistence.
> >
> > > > --
> > > > Ikai Lan
> > > > Developer Programs Engineer, Google App Engine
> > > > Blogger:http://googleappengine.blogspot.com
> > > > Reddit:http://www.reddit.com/r/appengine
> > > > Twitter:http://twitter.com/app_engine
> >
> > > > On Thu, Nov 25, 2010 at 12:38 AM, Eugene 

[appengine-java] Re: datanucleus-appengine

2010-12-03 Thread George Moschovitis
It 's counter productive for me, for the simple reason that I cannot
choose which API to
use:

- JPA seems to be the standard but it's geared towards RDBMS
- JDO is 'older' but better supports non relational DBs
- Both of the above seem abandoned (for example they use a very old
Datanucleus version)
- the Low level is too ..low level with no support of static typing
(one of the benefits of using Java)
- Twig has interesting features but seems to lack momentum
- Objectify seems to have more momentum, but is not standard, dunno if
this will be supported in a year or two
- etc, etc..."

As you can see I am on a deadlock, I cannot decide which API to use
and frankly all of the available options leave a lot
to be desired.

New features like (Channel API, Reserved instances, etc) may be cool,
but really GAE/J needs a solid, dependable database story...

just my 2 cents...
-g.


On Dec 3, 8:46 pm, "Ikai Lan (Google)" 
wrote:
> We'll investigate ways to keep JDO/JPA up to date.
>
> I disagree about the fact that having community driven libraries is counter
> productive. In fact, this is a sign of a thriving community. When evaluating
> our support of these libraries, we realized that we could have done a better
> job helping the folks building great tools for App Engine users. We've taken
> steps to better involve framework and library developers, and going forward,
> we will be having higher expectations for our own involvement helping these
> developers be successful.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
> On Fri, Dec 3, 2010 at 10:37 AM, George Moschovitis <
>
>
>
>
>
>
>
> george.moschovi...@gmail.com> wrote:
> > > We haven't abandoned JDO/JPA, but we may emphasize the low-level APIs
> > going
> > > forward. You'll always get low-level features first. The mismatch between
> > > datastore features and relational database features is starting to really
> > > grow.
>
> > I understand that emphasizing on the Low Level API makes sense, but
> > some work on JDO/JPA would be reasonable.
> > There is a lot of stuff that could be implemented on top of the
> > standard APIs.
>
> > Moreover, you could consider offering a custom Higher Level API, maybe
> > something similar to the Python version.
> > Having 10 slightly different community driven APIs is not productive.
>
> > regards,
> > -g.
>
> > > One thing we'll plan on doing is to work more closely with framework and
> > > library implementors to make sure they have what they need to build
> > toolkits
> > > that better mesh with non-relational datastores. For instance, take a
> > look
> > > at our recent article about Django:
>
> > >http://code.google.com/appengine/articles/django-nonrel.html
>
> > > (BTW, if you are a Python developer, please do not use app-engine-patch.
> > > It's deprecated).
>
> > > The original approach we took and encouraged was to bend existing
> > toolkits
> > > to work with GAE to adhere to standards. We'll still do this when
> > possible,
> > > but we're more pragmatic than dogmatic about standards. In some cases,
> > such
> > > as the datastore, it may make more sense for us to help developers build
> > > toolkits that can keep up with the trend of non-relational persistence.
>
> > > --
> > > Ikai Lan
> > > Developer Programs Engineer, Google App Engine
> > > Blogger:http://googleappengine.blogspot.com
> > > Reddit:http://www.reddit.com/r/appengine
> > > Twitter:http://twitter.com/app_engine
>
> > > On Thu, Nov 25, 2010 at 12:38 AM, Eugene D  wrote:
> > > > Great question. It would be very helpful to get a status report on
> > > > this as well as a roadmap for either this library or any planned
> > > > alternatives
>
> > > > On Nov 23, 3:48 pm, George  Moschovitis 
> > > > wrote:
> > > > > Are there any plans to resume work on datanucleus-appengine?
>
> > > > > The progress on this lib seems to have stopped 6 months ago and there
> > > > > still a lot of related issues in the tracker:
>
> > > > > update to the latest version of datanucleus, support for unowned
> > > > > relations, support for more jdo/jpa features, jpa docs and more...
>
> > > > > is there a roadmap for this important library?
>
> > > > > thanks,
> > > > > -g.
>
> > > > --
> > > > 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> > 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.

Re: [appengine-java] Re: datanucleus-appengine

2010-12-03 Thread Ikai Lan (Google)
We'll investigate ways to keep JDO/JPA up to date.

I disagree about the fact that having community driven libraries is counter
productive. In fact, this is a sign of a thriving community. When evaluating
our support of these libraries, we realized that we could have done a better
job helping the folks building great tools for App Engine users. We've taken
steps to better involve framework and library developers, and going forward,
we will be having higher expectations for our own involvement helping these
developers be successful.

--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blogger: http://googleappengine.blogspot.com
Reddit: http://www.reddit.com/r/appengine
Twitter: http://twitter.com/app_engine



On Fri, Dec 3, 2010 at 10:37 AM, George Moschovitis <
george.moschovi...@gmail.com> wrote:

> > We haven't abandoned JDO/JPA, but we may emphasize the low-level APIs
> going
> > forward. You'll always get low-level features first. The mismatch between
> > datastore features and relational database features is starting to really
> > grow.
>
> I understand that emphasizing on the Low Level API makes sense, but
> some work on JDO/JPA would be reasonable.
> There is a lot of stuff that could be implemented on top of the
> standard APIs.
>
> Moreover, you could consider offering a custom Higher Level API, maybe
> something similar to the Python version.
> Having 10 slightly different community driven APIs is not productive.
>
> regards,
> -g.
>
> >
> > One thing we'll plan on doing is to work more closely with framework and
> > library implementors to make sure they have what they need to build
> toolkits
> > that better mesh with non-relational datastores. For instance, take a
> look
> > at our recent article about Django:
> >
> > http://code.google.com/appengine/articles/django-nonrel.html
> >
> > (BTW, if you are a Python developer, please do not use app-engine-patch.
> > It's deprecated).
> >
> > The original approach we took and encouraged was to bend existing
> toolkits
> > to work with GAE to adhere to standards. We'll still do this when
> possible,
> > but we're more pragmatic than dogmatic about standards. In some cases,
> such
> > as the datastore, it may make more sense for us to help developers build
> > toolkits that can keep up with the trend of non-relational persistence.
> >
> > --
> > Ikai Lan
> > Developer Programs Engineer, Google App Engine
> > Blogger:http://googleappengine.blogspot.com
> > Reddit:http://www.reddit.com/r/appengine
> > Twitter:http://twitter.com/app_engine
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Nov 25, 2010 at 12:38 AM, Eugene D  wrote:
> > > Great question. It would be very helpful to get a status report on
> > > this as well as a roadmap for either this library or any planned
> > > alternatives
> >
> > > On Nov 23, 3:48 pm, George  Moschovitis 
> > > wrote:
> > > > Are there any plans to resume work on datanucleus-appengine?
> >
> > > > The progress on this lib seems to have stopped 6 months ago and there
> > > > still a lot of related issues in the tracker:
> >
> > > > update to the latest version of datanucleus, support for unowned
> > > > relations, support for more jdo/jpa features, jpa docs and more...
> >
> > > > is there a roadmap for this important library?
> >
> > > > thanks,
> > > > -g.
> >
> > > --
> > > 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.
>
> --
> 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.



[appengine-java] Re: datanucleus-appengine

2010-12-03 Thread George Moschovitis
> We haven't abandoned JDO/JPA, but we may emphasize the low-level APIs going
> forward. You'll always get low-level features first. The mismatch between
> datastore features and relational database features is starting to really
> grow.

I understand that emphasizing on the Low Level API makes sense, but
some work on JDO/JPA would be reasonable.
There is a lot of stuff that could be implemented on top of the
standard APIs.

Moreover, you could consider offering a custom Higher Level API, maybe
something similar to the Python version.
Having 10 slightly different community driven APIs is not productive.

regards,
-g.

>
> One thing we'll plan on doing is to work more closely with framework and
> library implementors to make sure they have what they need to build toolkits
> that better mesh with non-relational datastores. For instance, take a look
> at our recent article about Django:
>
> http://code.google.com/appengine/articles/django-nonrel.html
>
> (BTW, if you are a Python developer, please do not use app-engine-patch.
> It's deprecated).
>
> The original approach we took and encouraged was to bend existing toolkits
> to work with GAE to adhere to standards. We'll still do this when possible,
> but we're more pragmatic than dogmatic about standards. In some cases, such
> as the datastore, it may make more sense for us to help developers build
> toolkits that can keep up with the trend of non-relational persistence.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>
>
>
>
>
>
>
> On Thu, Nov 25, 2010 at 12:38 AM, Eugene D  wrote:
> > Great question. It would be very helpful to get a status report on
> > this as well as a roadmap for either this library or any planned
> > alternatives
>
> > On Nov 23, 3:48 pm, George  Moschovitis 
> > wrote:
> > > Are there any plans to resume work on datanucleus-appengine?
>
> > > The progress on this lib seems to have stopped 6 months ago and there
> > > still a lot of related issues in the tracker:
>
> > > update to the latest version of datanucleus, support for unowned
> > > relations, support for more jdo/jpa features, jpa docs and more...
>
> > > is there a roadmap for this important library?
>
> > > thanks,
> > > -g.
>
> > --
> > 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.

-- 
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: datanucleus-appengine

2010-11-29 Thread Ikai Lan (Google)
We haven't abandoned JDO/JPA, but we may emphasize the low-level APIs going
forward. You'll always get low-level features first. The mismatch between
datastore features and relational database features is starting to really
grow.

One thing we'll plan on doing is to work more closely with framework and
library implementors to make sure they have what they need to build toolkits
that better mesh with non-relational datastores. For instance, take a look
at our recent article about Django:

http://code.google.com/appengine/articles/django-nonrel.html

(BTW, if you are a Python developer, please do not use app-engine-patch.
It's deprecated).

The original approach we took and encouraged was to bend existing toolkits
to work with GAE to adhere to standards. We'll still do this when possible,
but we're more pragmatic than dogmatic about standards. In some cases, such
as the datastore, it may make more sense for us to help developers build
toolkits that can keep up with the trend of non-relational persistence.

--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blogger: http://googleappengine.blogspot.com
Reddit: http://www.reddit.com/r/appengine
Twitter: http://twitter.com/app_engine



On Thu, Nov 25, 2010 at 12:38 AM, Eugene D  wrote:

> Great question. It would be very helpful to get a status report on
> this as well as a roadmap for either this library or any planned
> alternatives
>
> On Nov 23, 3:48 pm, George  Moschovitis 
> wrote:
> > Are there any plans to resume work on datanucleus-appengine?
> >
> > The progress on this lib seems to have stopped 6 months ago and there
> > still a lot of related issues in the tracker:
> >
> > update to the latest version of datanucleus, support for unowned
> > relations, support for more jdo/jpa features, jpa docs and more...
> >
> > is there a roadmap for this important library?
> >
> > thanks,
> > -g.
>
> --
> 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.



[appengine-java] Re: datanucleus-appengine

2010-11-26 Thread Eugene D
Great question. It would be very helpful to get a status report on
this as well as a roadmap for either this library or any planned
alternatives

On Nov 23, 3:48 pm, George  Moschovitis 
wrote:
> Are there any plans to resume work on datanucleus-appengine?
>
> The progress on this lib seems to have stopped 6 months ago and there
> still a lot of related issues in the tracker:
>
> update to the latest version of datanucleus, support for unowned
> relations, support for more jdo/jpa features, jpa docs and more...
>
> is there a roadmap for this important library?
>
> thanks,
> -g.

-- 
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: datanucleus-appengine

2010-11-24 Thread George Moschovitis
The db story of GAE/J looks really sad:

- the low level api is erm... too low level.
- the 'official' datanucleus jdo/jpa apis seem abandoned.
- there are some interesting third party efforts (objectify, twig,
simpleds) but I don't really feel safe with third party solutions.

Given the fact that the db layer is central in typical web
applications, I would expect that Google provides a convincing
solution to this 'issue' ASAP.
It's unbelievable that only a single developer is (was?) working on
such a critical part or the GAE/J offering.

regards,
-g.

PS: How about bringing the original datanucleus developers on team?


On Nov 24, 11:56 am, Ian Marshall  wrote:
> +1 on this one. DataNucleus is a core library for those of us using
> JDO or JPA.
>
> I am fairly ruthless in avoiding third party plug-ins for my GAE/J app
> in order to minimise the risk of improvements stopping permanently,
> but I decided to use JDO so I have no choice but to depend on GAE's
> use of DataNucleus.
>
> Max Ross of Google seems to have disappeared from view since the end
> of August. He did (and hopefully still does) lots of datastore-related
> work.
>
> On Nov 23, 2:48 pm, George  Moschovitis 
> wrote:
>
>
>
>
>
>
>
> > Are there any plans to resume work on datanucleus-appengine?
>
> > The progress on this lib seems to have stopped 6 months ago and there
> > still a lot of related issues in the tracker:
>
> > update to the latest version of datanucleus, support for unowned
> > relations, support for more jdo/jpa features, jpa docs and more...
>
> > is there a roadmap for this important library?
>
> > thanks,
> > -g.

-- 
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: datanucleus-appengine

2010-11-24 Thread Ian Marshall
+1 on this one. DataNucleus is a core library for those of us using
JDO or JPA.

I am fairly ruthless in avoiding third party plug-ins for my GAE/J app
in order to minimise the risk of improvements stopping permanently,
but I decided to use JDO so I have no choice but to depend on GAE's
use of DataNucleus.

Max Ross of Google seems to have disappeared from view since the end
of August. He did (and hopefully still does) lots of datastore-related
work.


On Nov 23, 2:48 pm, George  Moschovitis 
wrote:
> Are there any plans to resume work on datanucleus-appengine?
>
> The progress on this lib seems to have stopped 6 months ago and there
> still a lot of related issues in the tracker:
>
> update to the latest version of datanucleus, support for unowned
> relations, support for more jdo/jpa features, jpa docs and more...
>
> is there a roadmap for this important library?
>
> thanks,
> -g.

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