I am trying to set up the following relation, but I am doubtful as to whether it is going to work:

class AvailabilityPage extends SiteTree {
	static $has_many = array(
		"HighSeasonIntervals" => "DateInterval",
		"FullyBookedIntervals" => "DateInterval"
	);
}

class DateInterval extends DataObject {
	static $db = array(
		"StartDate" => "Date",
		"EndDate" => "Date"
	);
	
	static $has_one = array(
		"AvailabilityPage" => "AvailabilityPage"
	);
}

The resulting database schema does not seem to distinguish between a DateInterval belonging either to the HighSeasonIntervals set on AvailabilityPage, or to the FullyBookedIntervals set. Does anyone know whether or not this is going to work?

If (as I suspect), it is not going to work directly, could anyone give me some pointers on how to implement such a relation? There is nothing on this topic in the Silverstripe documentation, unfortunately.

Many thanks in advance!

Now that I have thought about it some more, the impossibility of the relation I described above seems like a fundamental shortcoming of relational data models in general. Since any SQL database is a relational data model, it's never going to work :)

I have worked around the problem in the following (OO-wise ugly) way:

class AvailabilityPage extends Page {
	static $has_many = array(
		"HighSeasonIntervals" => "DateInterval_1",
		"FullyBookedIntervals" => "DateInterval_2"
	);
}

class DateInterval extends DataObject {
	static $db = array(
		"StartDate" => "Date",
		"EndDate" => "Date"
	);
}

class DateInterval_1 extends DateInterval {
	static $has_one = array(
		"AvailabilityPage" => "AvailabilityPage"
	);
}

class DateInterval_2 extends DateInterval {
	static $has_one = array(
		"AvailabilityPage" => "AvailabilityPage"
	);
}

Still, of course, if anyone has a better idea, I'd be glad to hear it. This might actually be quite an interesting general issue in object/relational mapping.

Actually this issue was addressed in 2.4! See http://open.silverstripe.org/ticket/4632 for more information.

Great! Thanks for pointing that out; I'll stick with my workaround this time (since I'm using 2.3.6), but I'll keep it in mind for future reference :)

Hi,

in a relational database you'd use a m:n relation. But that's indeed a mess to implement...