Mapping by code: collections of values not one-to-many?

36 views
Skip to first unread message

Dawid Ciecierski

unread,
May 9, 2014, 12:27:07 AM5/9/14
to nhibernate-...@googlegroups.com
Hello,

Let me say upfront that databases are not my area of expertise, so I may be saying something that is obviously wrong at first glance. (Apologies for wasting your time if this will turn out to be the case.) Secondly, this behaviour seems to be related to development a little more than users, thus posting here. 


The Problem
SimpleModelInspector does not recognise collections of simple values (example below) as one-to-many, while in my view such dependent collections should automatically be marked as such (as well as inverse). At first I thought that this was a glitch and aimed to write a test that would demonstrate it; however, to my surprise there are already tests proving the opposite behaviour! 

The tests in question are WhenCollectionOfComponentsThenNoMatch and WhenCollectionOfElementsThenNoMatch inside OneToManyTests. To my (untrained) eye it seems they should be demonstrating that a collection of components and a collection of elements should in fact be marked as one-to-many (which it is currently not).


Why?
The particular use case in case you're wondering: having cascade-on-delete enabled on collections inside auto-mapped classes:

public MyClass
{
public IList<string> Tags { get; set; }
}

public class MyModelMapper : ModelMapper
{
public MyModelMapper() : this(new SimpleModelInspector())
{
}

public MyModelMapper(IModelInspector modelInspector) : base(modelInspector)
{
BeforeMapList += CascadeDeleteForChildCollections;
}

private void CascadeDeleteForChildCollections(
IModelInspector inspector, 
PropertyPath member, 
ICollectionPropertiesMapper customizer)
{
if (inspector.IsOneToMany(member.LocalMember))
{
customizer.Inverse(true):
customizer.Key(k => k.OnDelete(OnDeleteAction.Cascade));
}
}
}

(I know it is not always the best+safest idea to casdade, but in this case these are some utility tables, and not part of the core business domain.)

Please do let me know if I'm wrong and this in fact is not a classic example of a one-to-many relationship, or if there perhaps exists another way to detect such collections with a model inspector and/or have them auto-SQL-cascade their deletes.

Best regards,
Dawid Ciecierski

Sergio Garcia

unread,
May 10, 2014, 1:04:10 PM5/10/14
to nhibernate-...@googlegroups.com
You should direct this question to the NHUSERS group (http://groups.google.com/group/NHUSERS/).  This group here is for the discussion of the development of NHibernate rather than development with NHibernate.




--

---
You received this message because you are subscribed to the Google Groups "nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhibernate-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ricardo Peres

unread,
May 11, 2014, 12:43:05 PM5/11/14
to nhibernate-...@googlegroups.com
Dawid,

"One-to-many", "many-to-one", "one-to-one" and "one-to-many" refer to relations between *entities*, not values. While NHibernate perfectly supports collections of values and components, which are not entities, it just does not call them "one-to-many", etc.

RP

Dawid Ciecierski

unread,
May 15, 2014, 6:37:15 AM5/15/14
to nhibernate-...@googlegroups.com
(Apologies for the late reply, I asked Google Groups to email replies to me directly but for some reason never got a notification.)

Sergio, I've posted a sister, more user-focused question on the nhusers group too but my post has not yet been approved; posted again a few minutes ago just in case. Wrote here first as at the time I thought it might be more of a dev question of the "should it behave this way" kind.

Ricardo, thank you for confirming that. I remember reading that on-delete-cascade can only be set for one-to-many relationships... and hence my quest for how this should be done for child collection continues. As I've written above, I've just posted on the nhusers group so hopefully we'll find a possibility there!

Thank you both for your input.

Regards,
Dawid
Reply all
Reply to author
Forward
0 new messages