-
1. Re: chromattic sameNameSiblings problem
julien_viet Jun 15, 2010 5:09 PM (in response to kentxu2007)1 of 1 people found this helpfulHi,
actually Chromattic is not designed to use same name siblings. My advice : if you can do without same name siblings, I think you should.
When we started to write it, we asked ourselves if it was relevant to provide support for this feature and it appeared that it would be simpler to not support it, as it was raising some technical issue I can't remember right now.
However it would be interesting actually to provide support for it in the future if there is a clear mapping between a JavaBean and a node type allowing same name siblings.
Same name siblings corresponding classes, could allow one to one named hierarchical relationship based on a multivalue like:
@OneTone
@MappedBy("child_name")
public abstract List<Child> getChild();
It would be easier to handle one to many
@OneToMany
public abstract List<AnyChildType> getChildren();
let me know
-
2. Re: chromattic sameNameSiblings problem
kentxu2007 Jun 15, 2010 9:47 PM (in response to julien_viet)Thank you for the feedback. I end up generating unique node name by suffix it with node UUID to work around this. The only trick here is to setName temporarily and change it after being persisted.
@PrimaryType(name = "ss:order")
class abstract Order {
@OneToMany
public abstract Collection<OrderUnit> getOrderUnits();@Create
protected abstract OrderUnit createOrderUnit();public OrderUnit addOrderUnit(...) {
OrderUnit unit=createOrderUnit();
unit.setName("unit");
getOrderUnits().add(unit);
unit.setName("unit-"+unit.getId());...
return unit;
}}
-
3. Re: chromattic sameNameSiblings problem
julien_viet Jun 16, 2010 2:46 AM (in response to kentxu2007)We have rarely this is used for GateIn, but I see now the problem you are facing.
The only thing I don't get is why you are using two steps and not set directly the name in the first setName ?
Actually for that kind of situation it could be possible and fairly easy to add in Chromattic a feature for automatic name generation in the next versions.
-
4. Re: chromattic sameNameSiblings problem
kentxu2007 Jun 16, 2010 3:28 AM (in response to julien_viet)Correct me if I am wrong here. The reason that I set the name twice is because I do not create my own unique name generator. I just use the node's UUID.
On one hand, I can not add a new child without first specify a name, this causes null path exception. On the other hand, I can not get the child UUID until it is added to the child collection, calling getId() before that would cause an illegal state exception. So, I am forced to set the name twice.
The following examples show the scenarios:
public OrderUnit addOrderUnit(...) {
OrderUnit unit=createOrderUnit();
getOrderUnits().add(unit); //<-- fails due to null path
unit.setName("unit-"+unit.getId());...
return unit;}
or
public OrderUnit addOrderUnit(...) {
OrderUnit unit=createOrderUnit();unit.setName("unit-"+unit.getId()); //<-- fails due to illegal state
getOrderUnits().add(unit);...
return unit;}
It would be great to see auto name generation feature in the next Chromattic release. Thank you.
-
5. Re: chromattic sameNameSiblings problem
julien_viet Jun 16, 2010 4:54 AM (in response to kentxu2007)In Chromattic 1.1 you can use setName to rename a persistent object, not in 1.0.
You can rename an object by using a Map<String, OrderUnit> (Map gives a lot of control on the node name) instead of Collection<OrderUnit> in your parent:
@OneToMany
public abstract Map<String, OrderUnit> getOrderUnits();
And then
OrderUnit unit = createOrderUnit();
getOrderUnits().put("unit", unit);
getOrderUnits().put("unit-" + unit.getId(), unit);
that should work.