Domain Model extension Patterns.

[Stephane Le Dorze]

Hi!

I had a reflexion relative to the extensibility of the Domain Model in the context of our environment.

Our framework is built in layers (at least the two exposed in this email - even if I forsee a third related to edition).

One comprise everything that is common to all our activities (users, inventories, etc..) and the second for the different activities themselves.

The activities will be added like plugins in the system.

Shipping new activities requiers to extend the Domain Model and use schema migration (that's fine).

These extensions are by design unidirectional; it makes no sense for the common part of the domain to have access to them.

(And I am telling that while begin sold by the "out of the tar pit" philosophy of no presumed access path - nice paper)

In fact it would not be problematic to have them, but..

if we decide to extend with a lot of activities (done by different teams); we'll quickly have name collisions and the common objects will become a gigantic bunch of senseless roles (with a number of relations that is proportional to the number of activities).

This could be adressed by making all activity domain objects inherit from an interface specific to each object it has a relation to.

But this does not scale to multiple relations as there's no multi-inheritance; so we're back to our issue.

I know that all fenix relations are bidirectional; hovewer I wonder if there could be some relaxation for unidirectional relations so that the common objects would not suffer of becoming blobesque entities (with a number of relations that is proportional to the number of activities)

Had you already found a similar need with any of your projects?

What do you think?

Stephane

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> I know that all fenix relations are bidirectional; hovewer I wonder if
> there could be some relaxation for unidirectional relations so that
> the common objects would not suffer of becoming blobesque entities
> (with a number of relations that is proportional to the number
> of activities)

Actually, you may have unidirectional relations in the fenix-framework.
You get them by not giving a name to a role.

For instance, using an example suggested by your domain, you may have
something along these lines:

// In the bottom layer
class User;

// In the upper layer
class MyActivity;

relation MyActivityUser {
User playsRole user;
MyActivity playsRole { multiplicity 0..*; }
}

This way, you will be able to traverse from the MyActivity to the User
(via the "user" role), but not the other way around.

Another alternative is if you want to compile things separately.

Imagine that you have your lower layer with its DML code and you compile it.

Then you want to compile the upper layer (or part of it, such as a new
activity) but still relate to the entities in the lower layer. In this
case, you will have a DML for the upper layer (or activity) where you
refer to the lower layer entities as external entities. For instance:

// These external entities come from the lower layer
external class User;

Then, you may have relations between your new entities and these
external entities that they will not change the external entities:

relation MyActivityUser {
User playsRole user;
MyActivity playsRole activities { multiplicity 0..*; }
}

This last option is not as well exercised as the one above and there may
be still some problems with it. Namely, because with the current
mapping scheme, we may have to change the database schema of an external
entity and I'm not sure if that is working (or how it should be done).

Was something along these lines what you were looking for?

Best regards,
--
João Cachopo

[Stephane Le Dorze]

I was not knowing it was already done.

Sounds great! :)

I now have to adapt our dsl and code generator to take advantge of this..

Thanks!

Stephane

--

You received this message because you are subscribed to the Google Groups "Fénix Framework" group.
To post to this group, send email to fenix-f...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fenix-framework?hl=.

[Stephane Le Dorze]

With this DML (part) :

relation NeighbourhoodHasModel {

  FFRoomNeighbourhood playsRole  {

    multiplicity *;

  }

  

  .net.blackmamba.persistence.asset.FFAssetModel playsRole model {

    multiplicity 1;

  }

  

}

I have this exception; any idea?

     [exec] Exception in thread "main" java.lang.Error: org.apache.ojb.broker.metadata.MetadataException: Can't find method set$null in net.blackmamba.persistence.asset.FFAssetModel

     [exec] at pt.ist.fenixframework.pstm.MetadataManager.<init>(MetadataManager.java:40)

     [exec] at pt.ist.fenixframework.pstm.MetadataManager.init(MetadataManager.java:47)

     [exec] at pt.ist.fenixframework.FenixFramework.initialize(FenixFramework.java:39)

     [exec] at com.playad.server.persistence.fenixframework.DelayedFenixInstanciationSing$.ensureCreation(FenixPersistenceServices.scala:33)

     [exec] at com.playad.server.persistence.fenixframework.DelayedFenixInstanciation.ensureCreation(FenixPersistenceServices.scala:47)

     [exec] at com.playad.server.persistence.fenixframework.FenixService$class.$init$(FenixPersistenceServices.scala:18)

     [exec] at sandbox.DeployDataBaseMain$.<init>(DeployDataBaseMain.scala:93)

     [exec] at sandbox.DeployDataBaseMain$.<clinit>(DeployDataBaseMain.scala)

     [exec] at sandbox.DeployDataBaseMain.main(DeployDataBaseMain.scala)

     [exec] Caused by: org.apache.ojb.broker.metadata.MetadataException: Can't find method set$null in net.blackmamba.persistence.asset.FFAssetModel

     [exec] at pt.ist.fenixframework.pstm.ojb.WriteOnlyPersistentField.findSetter(WriteOnlyPersistentField.java:60)

     [exec] at pt.ist.fenixframework.pstm.ojb.WriteOnlyPersistentField.<init>(WriteOnlyPersistentField.java:17)

     [exec] at pt.ist.fenixframework.pstm.OJBMetadataGenerator.updateCollectionDescriptorWithCommonSettings(OJBMetadataGenerator.java:303)

     [exec] at pt.ist.fenixframework.pstm.OJBMetadataGenerator.updateRelations(OJBMetadataGenerator.java:289)

     [exec] at pt.ist.fenixframework.pstm.OJBMetadataGenerator.updateOJBMappingFromDomainModel(OJBMetadataGenerator.java:90)

     [exec] at pt.ist.fenixframework.pstm.MetadataManager.<init>(MetadataManager.java:37)

     [exec] ... 8 more

[João Pereira]

I have also tried this and it seems that the current version is only
dealing well with unidirectional relations when the omitted role has
no multiplicity or multiplicity of 1.

Like this:

relation NeighbourhoodHasModel {
FFRoomNeighbourhood playsRole;

.net.blackmamba.persistence.asset.FFAssetModel playsRole model {
multiplicity 1;
}
}

Why is this happening I don't know.

Best regards,
João Pereira

On Wed, Nov 18, 2009 at 4:00 PM, Stephane Le Dorze

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> With this DML (part) :
>
> relation NeighbourhoodHasModel {
>   FFRoomNeighbourhood playsRole  {
>     multiplicity *;
>   }
>   
>   .net.blackmamba.persistence.asset.FFAssetModel playsRole model {
>     multiplicity 1;
>   }
>   
> }
>
> I have this exception; any idea?

It is a bug, as João pointed out, but I just committed a fix for it.

--
João Cachopo

[Stephane Le Dorze]

Great!

We'll be able to re-test it tomorrow.. :)

João Cachopo