[deepamehta-devel] some newbie dev migrations questions

Jörg Richter jri at deepamehta.de
Mo Feb 10 01:42:36 CET 2014


On Feb 9, 2014, at 10:24, carolina wrote:

>> You can't add new child types to an existing type with a
>> declarative migration (JSON). You would need an imperative
>> migration for that (Java, DM Core API). But see note below.
> 
> so in declarative migrations, it would only make sense to have
> different migration files for defining different types? i.e. define an
> event, define a location, etc ..?

You can create several things in a single declarative migration.
The general migration concept is: A migration represents a certain version of your data model that is compatible with a certain version of your plugin logic. Currently your plugin contains no logic (but just a data model), so this might be why you are confused. For differentiating declarative and imperative migrations see also the note below.

Read about DM migrations also here: https://trac.deepamehta.de/wiki/PluginDevelopmentGuide#Migrations
Don't hesitate to tell me where this explanation could be improved.

>> The DM runtime takes care of running migrations in the proper
>> order (1, 2, 3, ...) and that each migration is run exactly once.
>> This is because a migration expects a well-defined DB state and
>> leaves a well-defined DB state. If a migration which e.g. creates a
>> type would run twice the 2nd run would fail as the type already
>> exists. Declarative DM migrations (JSON) are not idempotent.
> 
> there is no "rollback" with declarative migrations, right?

You're right! Currently DM provides no way to "revert" a migration (as RoR does). This is a clear lack at the moment.

>>> btw is there a way to create again the database from scratch so
>>> to be able to run the first migration?
>> 
>> Indeed, resetting your DB is the most easy solution in your case:
>> 1) Stop DM 2) Delete the deepamehta-db folder (in the DM home 
>> directory) 3) Start DM This starts DM from scratch and runs your 
>> migrations starting from no. 1
> 
> :-)) ok after deleting the db and re-starting DM, the changes are
> applied :)))) but of course I lost all the previous data that I had
> :-D ... so the other question is which is the best way to have 2
> instances of DM installed, so one that can be a working copy and the
> other a dev copy.
> 
> 1.- Downloading the code twice and run them in different ports?

This would be the most flexible solution as you could run both DM instances at the same time.

> 2.- Defining 2 DB folders, one for dev and the other working copy?

This is a reasonable approach too. You can configure the DB folder via the <dm4.database.path> property in your global POM (in the DM home directory). Changes take effect after restarting DM.

IMPORTANT: only deploy stable versions of your plugin in your "production" instance. That is in particular: once a certain migration has run in your production instance you must make NO changes to that migration. There is no way to run that migration again. The only way to modify things created by a declarative migration is an imperative migration. See also the note below.

> 3.- ....any other.....
> 
>> Note: resetting the DB is a pragmatic way while development. In a 
>> production environment this is not an option of course. To add new 
>> child types to an existing type in a production environment you
>> MUST use an imperative migration (Java code, not JSON).
> 
> yes, for sure I'll have to move to use imperative migrations.

Only imperative migrations provides you with a full set of create, modify, delete operations as you might be familiar with from RoR migrations. But in DM you have to code migrations in Java. To free a developer from resorting to program in Java when she just want define a data model, DM introduces the concept of declarative migrations. Those allow you to define a data model declaratively (hence the name), namely in JSON. However, declarative DM migrations provide not the full expressiveness as the (imperative) Java language. With a declarative migration you can (currently) only *create* things, but not modify or delete things.

For an example of how to write an imperative migration see here:
https://trac.deepamehta.de/wiki/PluginDevelopmentGuide#Writinganimperativemigration
There a child type is added to an existing parent type (a modify operation). This is exactly the scenario you described originally with your Event (parent) type and Title and Text (child) types.

> For developing in Java I was planning to set it up in Emacs, that is
> what I use, I've seen
> 
> http://www.emacswiki.org/emacs/JavaDevelopmentEnvironment
> 
> has anybody used it? or makes more sense to use other IDE, like
> netbeans or...?

Bare bones Emacs (with several buffers open at once), a command line for building, plus the DM API Docs open in a browser window is all you need. But that's just my taste :-)

DM API Docs:
http://api.deepamehta.de/deepamehta/4.2-SNAPSHOT/

> Anyway first I will play around with json, for sure I will come up
> with more questions before getting into the need of imperative
> migrations ;-)

Your questions are very welcome :-))

Cheers,
Jörg




Mehr Informationen über die Mailingliste devel