1.1.1 released and 1.2 plans

[Guillaume Bort]

Hi all,

As no real problems have been reported about 1.1.1RC1, the Play 1.1.1
final release is now available.

This version is a maintenance release of Play 1.1 and doesn't provide
any new functionality. You can check the list of resolved issues in
the release notes page,
http://www.playframework.org/documentation/1.1.1/releasenotes-1.1.1

Now because I know it is frustrating to see a new release without new
functionality, here what you can expect for Play 1.2:

Already available in master:
- Ability to run Java test cases in any JUnit test runner (typically
directly in eclipse)
- Dependency management for both jars and modules
- Ability to customize the database/transaction management per request
- Built-in database migration tool (called 'evolutions')

Almost ready, and will be merged soon in master:
- New async system using continuations
- Streaming support for HTTP responses (chunked)
- H2 database instead of HSQL

Experimental, and in development:
- Dev web console to evaluate SQL and Java code in the context of a
running application
- Websocket support

We plan to release the 1.2 during March.

Have fun with Play!

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,
write guillau...@gmail.com

[Ω Alisson]

Wow, is there any documentation about the new async system?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Ivan San José García]

Sorry but, can you describe what means "New async system using continuations"?

2011/1/26 Ω Alisson <thelin...@gmail.com>:

[Jeffer]

Thanks for keeping us informed about the roadmap for play.  Would be great to have some insight on what's coming up in regards to Play with Scala (the Scala module if Scala's support is to be still managed that way).  You guys mentioned that quite big changes were coming up concerning the persistence layer, docs and also that there might be a new website or something.  There seems to be quite a bit of enthusiasm about Scala's support in Play but there isn't much information to be found in terms of future release plans...

Thanks for the great work!

[Olivier Refalo]

Good job, can only welcome H2 as the core embedded DB.

Where can we get more details about evolutions ?

Olivier

[Daniel Guryca]

Nice !

I am interested in evolutions too ...

Daniel

--

[mainframezen]

Continuations is like stop and go in your code. It works or pretends
to work as old school sequential programming, meaning that in the
middle of the code you need the user to do something and you "stop"
the program waiting on input, in this case waiting for the browser, or
maybe it can even implement websockets (HTML5 feature).

Don't know really what are the details.

On Jan 26, 6:28 pm, Ivan San José García <ivan...@gmail.com> wrote:
> Sorry but, can you describe what means "New async system using continuations"?
>

> 2011/1/26 Ω Alisson <thelinuxl...@gmail.com>:

>
> > Wow, is there any documentation about the new async system?
>

> > On Wed, Jan 26, 2011 at 4:04 PM, Guillaume Bort <guillaume.b...@gmail.com>

> >> Guillaume Bort,http://guillaume.bort.fr

>
> >> For anything work-related, use g...@zenexity.fr; for everything else,

> >> write guillaume.b...@gmail.com

[mainframezen]

yes, evolutions are very important. Rails has them (migrations).

There is also Scala Migrations for that. I thought it would be the
choice.

On Jan 26, 7:1al pm, Daniel Guryca <dun...@gmail.com> wrote:
> Nice !
>
> I am interested in evolutions too ...
>
> Daniel
>

> On Wed, Jan 26, 2011 at 7:44 PM, Olivier Refalo <oref...@yahoo.com> wrote:
> > Good job, can only welcome H2 as the core embedded DB.
>
> > Where can we get more details about evolutions ?
>
> > Olivier
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-fr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go­oglegroups.com>
> > .

[Paulo Coutinho]

Do you plan make profiles for querys with html result, like YiiFramework?

Log all queries in a html file.

2011/1/26 Guillaume Bort <guillau...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
Atenciosamente,
Paulo Coutinho.
Blog: www.prsolucoes.com/blog
Site: www.prsolucoes.com
Msn:  pa...@prsolucoes.com
Skype: paulo.prsolucoes
Consultor Certificado Bindows

[Martin Aspeli]

Hi Guillaume,

Great work! I can't wait for 1.2. ;-)

I noticed that my javax.inject fix was integrated into 1.1.1, but the
Fixtures.load() change was not.

Was there a specific reason for this, or just lack of time? Anything I
can do to help make sure it's integrated into 1.1.2 or 1.2?

Cheers,
Martin

[Drew]

Hi Guillaume,

Where can I find more info on "- Ability to customize the database/
transaction management per request"

Thanks,

Drew

On Jan 26, 10:04 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> Hi all,
>
> As no real problems have been reported about 1.1.1RC1, the Play 1.1.1
> final release is now available.
>
> This version is a maintenance release of Play 1.1 and doesn't provide
> any new functionality. You can check the list of resolved issues in

> the release notes page,http://www.playframework.org/documentation/1.1.1/releasenotes-1.1.1

>
> Now because I know it is frustrating to see a new release without new
> functionality, here what you can expect for Play 1.2:
>
> Already available in master:
> - Ability to run Java test cases in any JUnit test runner (typically
> directly in eclipse)
> - Dependency management for both jars and modules
> - Ability to customize the database/transaction management per request
> - Built-in database migration tool (called 'evolutions')
>
> Almost ready, and will be merged soon in master:
> - New async system using continuations
> - Streaming support for HTTP responses (chunked)
> - H2 database instead of HSQL
>
> Experimental, and in development:
> - Dev web console to evaluate SQL and Java code in the context of a
> running application
> - Websocket support
>
> We plan to release the 1.2 during March.
>
> Have fun with Play!
>
> --

> Guillaume Bort,http://guillaume.bort.fr

>
> For anything work-related, use g...@zenexity.fr; for everything else,

> write guillaume.b...@gmail.com

[Guillaume Bort]

There is no documentation yet sorry, but the idea is to be able to
write code like this in controllers:

public static void getNewMessages(String chatRoom) {
ChatRoom room = ChatRoom.get(chatRoom);
List<Message> messages = wait( room.getNewMessages() );
renderJSON(messages);
}

Here room.getNewMessages() returns a Task<List<Message>> (which is
also a Future<List<Message>>). And wait is the merged
suspend/continuation mechanism.

When you call wait(...) the current execution stack is frozen and
returned to the framework with the associated future task. When the
future task is completed the action will be invoked again and will
continue from the frozen point.

Another example:

public static void createMashupPage() {
Task<HttpResponse> videos =
WS.url("http://www.vimeo.com/....").async().get();
Task<HttpResponse> news =
WS.url("http://www.tumblr.com/....").async().get();
Task<HttpResponse> code =
WS.url("http://www.github.com/....").async().get();
List<HttpResponse> neededResources = wait( Task.waitAll(videos,
news, code) );
renderPage(neededResources);
}

Again wait(...) will free the thread until 3 http request are actually
completed.

Or to generate a large CSV response and stream the result:

public static void generateVeryLargeReport() {
CSVReport report = new CSVReport();
while(report.hasMoreData()) {
ReportData data = wait( report.nextData() );
renderChunk(data);
}
}

Here the while loop uses continuations and is non-blocking.

And we will of course use the same mechanism to properly handle WebSockets.

2011/1/26 Ω Alisson <thelin...@gmail.com>:

[Guillaume Bort]

Yes I know we are terribly late on these tasks.

The scala module is a separated project. But it looks like the data
access component is almost ready, and I now need to check it and to
update the sample applications and documentation.

[Guillaume Bort]

You can take a look at:

https://github.com/playframework/play/blob/master/samples-and-tests/just-test-cases/app/controllers/Transactional.java

The engine is now ready and we will add more annotations like
@NoTransaction, @NoDatabase, etc... Btw the mechanism is totally
generic and can be used to customize any plugin based on the request
annotations.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,

write guillau...@gmail.com

[Alison Winters]

Hi Guillaume,

Thanks for the roadmap update. I am very much looking forward to
Evolutions, since the DB Migrate module seems to be stuck on 1.0.3.2.
I just had a look at the source code for it and it looks like it will
work fairly smoothly. A few comments/questions:

- Is it possible to allow for a filename that isn't just 1.sql, 2.sql
etc? This would make it easier to see from the filename what the
version number was supposed to do. E.g. as per DB Migrate module, have
1.CreateUserTables.sql. This would also be nice to add a "name" for
the Evolution in the database, which makes it a bit clearer to the
user what is missing from their configuration before they upgrade.
Right now i think it just shows you the raw SQL which may not be easy
to understand if there is a lot there.

- I presume you made the decision deliberately to put both upgrades
and downgrades in the same SQL instead of separating them as per the
DB Migrate module. Is there a reason why you did this? The nice thing
about having them in separate files is it's very easy to run or re-run
a broken SQL from the command line without needing to edit the "main"
table. I see you have a hashcode stored for each Evolution, this is
very cool but will it allow for the case where in development you
create an Evolution then realize you screwed up the SQL so you need to
roll it back and reapply it with the new upgrade code?

- Is there any chance you will build a migration script for people
with existing migrations in the DB Migrate module format? Migrating
the SQLs will be easy, but creating and updating the new tables may be
a little trickier. Would your recommendation be to "reset" the
database to version 1 when moving to Evolutions? I hope not because we
have our entire DB schema in the DB Migrate module format at the
moment.

For those of you who are curious about this feature, the major
changeset is here: https://github.com/playframework/play/commit/abf6b028a4c072428ed26bb9de4ff06cd158395b

Alison

On Jan 26, 1:04 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> Hi all,
>
> As no real problems have been reported about 1.1.1RC1, the Play 1.1.1
> final release is now available.
>
> This version is a maintenance release of Play 1.1 and doesn't provide
> any new functionality. You can check the list of resolved issues in

> the release notes page,http://www.playframework.org/documentation/1.1.1/releasenotes-1.1.1

>
> Now because I know it is frustrating to see a new release without new
> functionality, here what you can expect for Play 1.2:
>
> Already available in master:
> - Ability to run Java test cases in any JUnit test runner (typically
> directly in eclipse)
> - Dependency management for both jars and modules
> - Ability to customize the database/transaction management per request
> - Built-in database migration tool (called 'evolutions')
>
> Almost ready, and will be merged soon in master:
> - New async system using continuations
> - Streaming support for HTTP responses (chunked)
> - H2 database instead of HSQL
>
> Experimental, and in development:
> - Dev web console to evaluate SQL and Java code in the context of a
> running application
> - Websocket support
>
> We plan to release the 1.2 during March.
>
> Have fun with Play!
>
> --

> Guillaume Bort,http://guillaume.bort.fr

>
> For anything work-related, use g...@zenexity.fr; for everything else,

> write guillaume.b...@gmail.com

[Guillaume Bort]

The implementation is here:

https://github.com/playframework/play/blob/master/framework/src/play/db/Evolutions.java

Basically you have to create a db/evolutions directory in your
application. Each evolution is an SQL script in this directory
(starting at 1.sql)

In this SQL script you have 2 parts, Ups and Downs. For example:

1.sql
-------

# ---- !Ups

CREATE TABLE customer (First_Name char(50), Last_Name char(50));

# ---- !Downs

DROP TABLE customer;

Of course the engine takes care of detecting and resolving conflicts,
for example if 2 developers create a 2.sql evolution script
independently.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
>

--

[Guillaume Bort]

On Thu, Jan 27, 2011 at 12:00 AM, Alison Winters <alison...@gmail.com> wrote:
> Hi Guillaume,
>
> Thanks for the roadmap update. I am very much looking forward to
> Evolutions, since the DB Migrate module seems to be stuck on 1.0.3.2.
> I just had a look at the source code for it and it looks like it will
> work fairly smoothly. A few comments/questions:
>
> - Is it possible to allow for a filename that isn't just 1.sql, 2.sql
> etc? This would make it easier to see from the filename what the
> version number was supposed to do. E.g. as per DB Migrate module, have
> 1.CreateUserTables.sql. This would also be nice to add a "name" for
> the Evolution in the database, which makes it a bit clearer to the
> user what is missing from their configuration before they upgrade.
> Right now i think it just shows you the raw SQL which may not be easy
> to understand if there is a lot there.

In my idea it's better to keep predictable file names for evolution
and to add comments directly inside the sql script. Why? Because if 2
developers create both 2.sql scripts, it will force one developer to
merge both during the 'git merge'. Then the merged 2.sql script will
be detected as different by the evolutions engine, and it will apply
OLD 2 DOWNS and NEW 2 UPS.

> - I presume you made the decision deliberately to put both upgrades
> and downgrades in the same SQL instead of separating them as per the
> DB Migrate module. Is there a reason why you did this? The nice thing
> about having them in separate files is it's very easy to run or re-run
> a broken SQL from the command line without needing to edit the "main"
> table. I see you have a hashcode stored for each Evolution, this is
> very cool but will it allow for the case where in development you
> create an Evolution then realize you screwed up the SQL so you need to
> roll it back and reapply it with the new upgrade code?
>

Yes if you modify your last evolution script, it will be detected as a
new evolution and it will apply OLD DOWNS and NEW UPS. If it can't
because of SQL error, it will ask you to manually resolve the conflict
(I'm not sure that the manual conflict resolution step is actually
already implemented).

> - Is there any chance you will build a migration script for people
> with existing migrations in the DB Migrate module format? Migrating
> the SQLs will be easy, but creating and updating the new tables may be
> a little trickier. Would your recommendation be to "reset" the
> database to version 1 when moving to Evolutions? I hope not because we
> have our entire DB schema in the DB Migrate module format at the
> moment.
>

I'm not sure. The current migrate module is not mine and I have to
check exactly how it works.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,

write guillau...@gmail.com

[Alison Winters]

Hi Guillaume,

Thanks for the quick reply. Your reasoning sounds sensible to me,
especially given there is good support for rollback/reapply.

It might still be nice to give each Evolution a user-readable name.
Perhaps have a !name or !description tag for each Evolution that would
describe what the SQL was going to do. Then the code could strip all
of those and list them at the top of the upgrade message instead of
just displaying a long block of SQL with all the concatenated
upgrades. What do you think?

The other big concern I have is requiring dev mode to apply the
upgrades. This is fine for the development/staging environment, but I
would be scared to bring the app up in dev mode on the production
server and risk a normal user accessing the site before the upgrade
has run - then they can see and run SQL code in our DB, as well as
access other dev mode features. I think it's very important to at
least have an option to run this automatically in prod mode
onApplicationStart, before any further DB access takes place.

Alison

On Jan 26, 6:13 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:

> > changeset is here:https://github.com/playframework/play/commit/abf6b028a4c072428ed26bb9...

[Daniel Guryca]

Indeed very interesting ...

Daniel

2011/1/26 Guillaume Bort <guillau...@gmail.com>

[Drew]

From the looking at the code, seems like Transaction management is
only for JPA right? I mean there's still no Play JTA transaction? Is
that true?

- Drew

On Jan 26, 2:57 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> You can take a look at:
>

> https://github.com/playframework/play/blob/master/samples-and-tests/j...

[grandfatha]

I cant wait for the 1.2 final release. Inspirational roadmap!

Is it feasible to run the git-version of Play? Or is it too cutting
edge? ;)

I am asking, because I often would like to contribute to Play, but as
I am running on the stable release, it would be too much time spent to
always get the new version, built it, run my app against it, make
changes, create a patch, etc for often small changes. If I was always
on the latest version, this could be reduced a lot.

Do you recommend running the latest version?

[Guillaume Bort]

Yes the master version is usually stable enough to be used in development.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,

write guillau...@gmail.com