Re: [Lift] Re: ManyToMany decision

It turns out that foreign keys not being created by Schemifier was DB specific -- to my knowledge only H2. Hopefully that will get fixed. Although it doesn't specify an action - cascade etc. So do we want a way to tell Schemifier what action to use for FK constraints? Or do we want Mapper to manage

[Lift] Re: ManyToMany decision

http://reviewboard.liftweb.net/r/101/ From my the end of my description: Please advise me as to what testing is appropriate. Also, when it finds broken joins should it log them? On Thu, Nov 12, 2009 at 9:28 PM, Naftoli Gugenheim wrote: > In any case, the

[Lift] Re: ManyToMany decision

In any case, the major problem with silently dropping children not in the join table is that it becomes necessary to take indexes into the children table and convert them to indexes into the join table. Any ideas how to go about doing so, without scanning the join table for broken entries each time

[Lift] Re: ManyToMany decision

Interesting. Did you see mapper.view.ItemsList? - glenn wrote: There is a related issue that if implemented, would certainly make the Mapper framework more robust - that of marking table rows for deletion, rather than deleting them directly. Some RDBMS's hav

[Lift] Re: ManyToMany decision

I guess it's about two separate things: cascading delete, as you said; and that it should silently skip dead-end joins rather than throwing an error. Note that I'm not aware of an issue with OneToMany cascading deletes (although in order to tell it to, you have to mix in Cascade). What we have

[Lift] Re: ManyToMany decision

There is a related issue that if implemented, would certainly make the Mapper framework more robust - that of marking table rows for deletion, rather than deleting them directly. Some RDBMS's have a built-in marking function, and another function that actually removes rows that have been so marke

[Lift] Re: ManyToMany decision

Naftoli, Isn't this really a cascading delete issue and not one isolated to ManyToMany situations? Most ORM solutions allow for cascading deletes. Such a feature could be added to the Mapper class, itself, and hold a list of foreign key assignments that the delete function could iterate over, if

[Lift] Re: ManyToMany decision

To clarify: The fundamental purpose of ManyToMany, like OneToMany, is that rather than dealing with "children" of an entity as they are in the database at a given moment, instead, they should have similar semantics to a MappedField: You load it from the database, modify it to your hearts conten

[Lift] Re: ManyToMany decision

On Tue, Nov 10, 2009 at 2:16 PM, Naftoli Gugenheim wrote: > Hello. > When I wrote ManyToMany a couple of months ago, I designed it to internally > hold a collection of join table records, and to act as a collection of > elements of the child table. > For example, given Volunteer and VolunteerGroup