With Google's announcement of support for Java in their App Engine, Persevere now has the potential to run on GAE. I have reviewed the GAE docs, and it doesn't look like there would be any serious problems with running Persevere. However, GAE does prevent file write access, so Persevere's default storage engine could not run, but within the context GAE, I would think it would be preferable to use Google's provided data store anyway (the BigTable database). Therefore, the main effort that would be required would be writing a data source adapter for Google's data store API for their database. The BigTable database would actually fit very nicely with Persevere, since I believe it supports very dynamic table structures with expando properties on objects. One would probably be able to retain pretty comprehensive support for Persevere's broad range of persistence capabilities on GAE.
Support for GAE is therefore something I would really like to see added to Persevere. Besides noting that this is on the roadmap, I also wanted to see if anyone was interested in working on this. Creating data source adapters is a relatively self-contained project (in comparison to other feature additions), so it might be a reasonable, fun project. If not, I do still plan on adding support for GAE, albeit it will probably remain lower priority than bug fixes/stabilization, and some of the more immediate efforts.
This is very good news. I have quite a lot to do, but a data source adapter
would be something that would benefit essentially all SSJS projects, so
maybe we could form a joint team? I'll help as much as I can.
Cheers,
PS
On Fri, Apr 10, 2009 at 3:57 PM, Kris Zyp <kris...@gmail.com> wrote:
> With Google's announcement of support for Java in their App Engine,
> Persevere now has the potential to run on GAE. I have reviewed the GAE
> docs, and it doesn't look like there would be any serious problems with
> running Persevere. However, GAE does prevent file write access, so
> Persevere's default storage engine could not run, but within the context
> GAE, I would think it would be preferable to use Google's provided data
> store anyway (the BigTable database). Therefore, the main effort that
> would be required would be writing a data source adapter for Google's
> data store API for their database. The BigTable database would actually
> fit very nicely with Persevere, since I believe it supports very dynamic
> table structures with expando properties on objects. One would probably
> be able to retain pretty comprehensive support for Persevere's broad
> range of persistence capabilities on GAE.
> Support for GAE is therefore something I would really like to see added
> to Persevere. Besides noting that this is on the roadmap, I also wanted
> to see if anyone was interested in working on this. Creating data source
> adapters is a relatively self-contained project (in comparison to other
> feature additions), so it might be a reasonable, fun project. If not, I
> do still plan on adding support for GAE, albeit it will probably remain
> lower priority than bug fixes/stabilization, and some of the more
> immediate efforts.
When Persevere ran on GAE, what about the usual suspects:
- ACID compliancy
- Cascading deletes
- Referential integrity: For instance when a product is deleted, all
orders containing
this product are deleted/changed, too ...
On May 26, 5:30 pm, Rav <ravsob...@gmail.com> wrote:
I have not been working on it, because I have been focusing on finishing
stability work and addressing other issues. That would be great if you
would like to help though. Probably the primary effort towards making
Persevere work on GAE is building data source adapter to GAE's BigTable
interface. We currently have a data source adapter for SQL databases
(org.persvr.datasource.DatabaseTableDataSource), but they rely on the
JDBC interface. So they would have to be converted to using GAE's API.
BTW, has anyone actually tried to startup Persevere on GAE? There will
probably be some other minor issues, like I think we will to need to
make sure the task timer (used for setTimeout, setInterval, etc.)
gracefully fails, since it wouldn't be allowed to run in GAE.
Kris
On 6月26日, 下午10時49分, Kris Zyp <kris...@gmail.com> wrote:
> I have not been working on it, because I have been focusing on finishing
> stability work and addressing other issues. That would be great if you
> would like to help though. Probably the primary effort towards making
> Persevere work on GAE is building data source adapter to GAE's BigTable
> interface. We currently have a data source adapter for SQL databases
> (org.persvr.datasource.DatabaseTableDataSource), but they rely on the
> JDBC interface. So they would have to be converted to using GAE's API.
Thanks, I'm digging into it to see if there is a reasonable way to
convert it.
> BTW, has anyone actually tried to startup Persevere on GAE? There will
> probably be some other minor issues, like I think we will to need to
> make sure the task timer (used for setTimeout, setInterval, etc.)
> gracefully fails, since it wouldn't be allowed to run in GAE.
> Kris
I didn't try that yet but, as you say, due to the permission
configuration of GAE, any thing involved Thread and arbitrary file IO
will be denied.
Another thing to ask, if there is a way to test Persevere DataSource
API without starting a Persevere instance?
Also, it is worth noting that I would like to look at providing an alternate JavaScript API for defining data sources for Persevere in the future. The current datasource API plugin is built for data sources coded in Java (primarily so that data sources can be highly performant), but it would be nice to make it easier for devs to stay in JS end-to-end. If you would like to help define such an API, you could certainly look at creating a BigTable/GQL data source, albeit that data source will still entail interaction with the BigTable Java APIs (which can be done through JS).
sleepnova wrote: > On 6月26日, 下午10時49分, Kris Zyp <kris...@gmail.com> wrote:
>> I have not been working on it, because I have been focusing on finishing >> stability work and addressing other issues. That would be great if you >> would like to help though. Probably the primary effort towards making >> Persevere work on GAE is building data source adapter to GAE's BigTable >> interface. We currently have a data source adapter for SQL databases >> (org.persvr.datasource.DatabaseTableDataSource), but they rely on the >> JDBC interface. So they would have to be converted to using GAE's API.
> Thanks, I'm digging into it to see if there is a reasonable way to > convert it.
>> BTW, has anyone actually tried to startup Persevere on GAE? There will >> probably be some other minor issues, like I think we will to need to >> make sure the task timer (used for setTimeout, setInterval, etc.) >> gracefully fails, since it wouldn't be allowed to run in GAE. >> Kris
> I didn't try that yet but, as you say, due to the permission > configuration of GAE, any thing involved Thread and arbitrary file IO > will be denied.
Exactly. The timer uses threads, and so I think I could just catch the error and have setTimeouts fail when running in GAE. File IO means the default DB (JavaScriptDB) can't be used, a BigTable data source adapter will have to be used for all the storage in Persevere (which is kind of the point of GAE).
> Another thing to ask, if there is a way to test Persevere DataSource > API without starting a Persevere instance?
No, I haven't created any type of test harness for doing that.
Yes, that is also what I'm thinking about. If you don't mind, please point out what layer or where can I looking to implement or provide alternative way to it, thanks!
> Also, it is worth noting that I would like to look at providing an > alternate JavaScript API for defining data sources for Persevere in the > future. The current datasource API plugin is built for data sources > coded in Java (primarily so that data sources can be highly performant), > but it would be nice to make it easier for devs to stay in JS > end-to-end. If you would like to help define such an API, you could > certainly look at creating a BigTable/GQL data source, albeit that data > source will still entail interaction with the BigTable Java APIs (which > can be done through JS).
> sleepnova wrote: > > Another thing to ask, if there is a way to test Persevere DataSource > > API without starting a Persevere instance?
> No, I haven't created any type of test harness for doing that.
It seems that I will have a hard time start and restart in order to test and debug it. -.-