Re: new convenience methods (was Re: PyDO bugs)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 11, 2005, at 11:28, Jacob Smullyan wrote:

> I'm actually a bit annoyed by using these new methods I created,
> because they require that the other PyDO class to which there is a
> relationship be already defined when the relationship is defined.
> That means that I have to do things like this:
>
>    class A(PyDO):
>       pass
>
>    class B(PyDO):
>       getA=OneToMany('a_id', 'id', A)
>
>    A.relatedB=ForeignKey('a_id', 'id', B)
>
> That's OK, but not fantastic.  Before, the references to related
> classes were in methods that were evaluated at runtime, not class
> definition time, so this problem wasn't present.  Anyone have a bright
> idea of how to avoid this?

I've been thinking a little more of this in light of the relatively 
complicated approach I outlined previously. Although I'm not sure if it 
addresses your concern regarding runtime vs. class creation time, but 
why not treat relationships as classes themselves? I mean if we're 
truly deconstructing a real object metaphor here, one has to have at 
least two (not necessarily distinct) entities to form a relationship, 
right? What about doing something like this:

	-- MySQL-like syntax, but hopefully you get the idea

	CREATE TABLE first_table
	(
		'id' SERIAL PRIMARY KEY,
		...
	);

	CREATE TABLE second_table
	(
		'id' SERIAL PRIMARY KEY,
	    first_id BIGINT UNSIGNED NOT NULL,
	    INDEX (first_id),
	    FOREIGN KEY (first_id)
			REFERENCES first_table (id) ON DELETE CASCADE,
		...
	);

	CREATE TABLE third_table
	(
		'id' SERIAL PRIMARY KEY,
		...
	);

	CREATE TABLE pivot_table
	(
	    second_id BIGINT UNSIGNED NOT NULL,
	    INDEX (second_id),
	    FOREIGN KEY (second_id)
			REFERENCES second_table (id) ON DELETE CASCADE,
	    third_id BIGINT UNSIGNED NOT NULL,
	    INDEX (third_id),
	    FOREIGN KEY (third_id)
			REFERENCES third_table (id) ON DELETE CASCADE,
		...
	);

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	import pydo

	class FirstTable(pydo.PyDO):
		table = 'first_table'
		fields = (Sequence('id'), ...)
		...

	class SecondTable(pydo.PyDO):
		table = 'second_table'
		fields = (Sequence('id'), 'first_id', ...)
		...

	class ThirdTable(pydo.PyDO):
		table = 'third_table'
		fields = (Sequence('id'), ...)
		...

	class PivotTable(pydo.PyDO):
		table = 'pivot_table'
		fields = ('second_id', 'third_id', ...)
		...

	class FirstParentsSecond(pydo.OneToManyRelationship):
		one = FirstTable
		oneField = 'id'
		many = SecondTable
		manyField = 'first_id'
		...

	class SecondThirdSiblings(pydo.ManyToManyRelationship):
		left = SecondTable
		leftField = 'id'
		right = ThirdTable
		rightField = 'id'
		pivot = PivotTable
		pivotLeftField = 'second_id'
		pivotRightField = 'third_id'
		...

	seconds = SecondThirdSiblings.getLefts(rightVal = 2)

These may even be able to be objects (instead of classes), since they 
would probably only represent the execution of select statements, and 
hence, probably only return objects of the record types:

	secondThirdSiblingsObj = pydo.ManyToManyRelationship(
		left = SecondTable,
		leftField = 'id',
		right = ThirdTable,
		rightField = 'id',
		pivot = PivotTable,
		pivotLeftField = 'second_id',
		pivotRightField = 'third_id')

	thirds = secondThirdSiblingsObj.getRights(leftVal = 5)

	# I'm not sure what these would return, but I'm trying to
	# capture the idea that one could return objects which
	# might contain values from columns not just in the right
	# table, also from the pivot or left table as well
	secondThirdSiblingsObj.getRightsWithPivotColumns(leftVal = 5)
	secondThirdSiblingsObj.getAllColumns(leftVal = 5)

This may be a radically different approach than what PyDO has taken 
before, and I am not familiar enough with PyDO's architecture to know 
if this plays nicely with PyDO's existing object/class metaphor(s) or 
conventions. However, the idea seemed elegant enough to me (at least on 
the face of it) to invite criticism.

If reducing boilerplate is what PyDO is after with its new convenience 
methods, I think convenience classes might be a viable alternative.

Just more random thoughts....

	-- Matt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFC/X6NnLpDzL5I7l8RAjsYAJ9OcpN73g29axRfb7Oo1IGpZy20YgCfbhht
WMbIICBvZsGQbx0Qzg9ezRU=
=1Mn8
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf