[play 2.0] Initialize data for application

[Eric]

Hi,

I'm migrating my early stage project from 1.2.3 to 2.0, as the first release is planned in mid-2012. I want to be comfortable with 2.0.

We had the initial-data.yaml, loaded by the Bootstrap class annoted with @OnApplicationStart, using the Fixtures.load stuff. It was great.

I've understand the db/evolutions features, which is great too but do I have to create an db/evolutions plain sql script to initialize the application ?

[Guillaume Bort]

There is now a Global object you can use to define additional code
that must run at application start/stop.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/93y1Gg6wAh0J.
> 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

[Eric]

To be more precise, I was searching the equivalent of the Fixtures.loadModel of 1.2.3.

If I'm taking example on the zentasks sample, here is the code to initialize the application :

public class Global extends GlobalSettings {

    

    public void onStart(Application app) {

        InitialData.insert(app);

    }

    

    static class InitialData {

        

        public static void insert(Application app) {

            if(Ebean.find(User.class).findRowCount() == 0) {

                

                Map<String,List<Object>> all = (Map<String,List<Object>>)Yaml.load(

                    app.resourceAsStream("conf/initial-data.yml"),

                    app.classloader()

                );

                // Insert users first

                Ebean.save(all.get("users"));

                // Insert projects

                Ebean.save(all.get("projects"));

                for(Object project: all.get("projects")) {

                    // Insert the project/user relation

                    Ebean.saveManyToManyAssociations(project, "members");

                }

                // Insert tasks

                Ebean.save(all.get("tasks"));

                

            }

        }

        

    }

    

}

In Play 1.2.3, we had 

@OnApplicationStart

public class Bootstrap extends Job {

    /**

     * 

     */

    public void doJob() {

        if (User.count() == 0) {

            Fixtures.loadModels("initial-data.yml");          

        }

    }

}

This new 2.0 way of doing this does not seem like a progress to me :(

[Guillaume Bort]

It is because the old Fixtures.loadModels was really limited:

- No ability to use custom features in YAML file.
- impossibility to handle cyclic reference.
- Bound to JPA and useless for any other persistence engine.
- Impossibility to have dynamic values (well I know that the ability
to use groovy code in it solved some cases but not for real world
usage).

That's why I decided in Play 2.0 to let a simple YAML helper able to
load any existing YAML description and let the user code to handle it
in any way he want.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/SYQRUmbqNx8J.

[Manuel Bernhardt]

+1 on detaching the YAML loading from Model. I ended up customizing
that one with Play-Java to be able to address dynamic cases, with a
couple of callbacks.

I did not have time to check the YamlLoader in Play 2.0 but the one in
the scala module wrapping SnakeYaml was pretty limited, it missed a
lot of types (lists, maps, Options, but also custom types such as BSON
ObjectIds etc.). Is that adressed and are there hooks to handle
custom types?

Manuel

[Guillaume Bort]

I didn't found any good Yaml parser for Scala. But, I think that is
not useful for Scala anyway since you can easily declare your object
graph literally as code.

--
Guillaume Bort