Re: PyDO bugs

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

This seems like a very worthy improvement, and I'm happy to see its 
introduction in this version of PyDO. It got me thinking though....

Will these relationships also be inferred by the pydo.autoschema() 
function? If not, I guess one could always add them to the classes 
after they were returned (but this seems to defeat the purpose of 
having a function like autoschema()).

OneToMany relationships are probably inferable as opposite directions 
from ForeignKey relationships (and even then, it may be one-to-one in 
practice). ManyToMany relationships would probably always have to be 
done by hand unless the common pattern of a mapping table was 
recognized. Or (more generally) a (not necessarily useful) ManyToMany 
relationship could be inferred between each pair of foreign keys found 
in a single table with two or more foreign keys.

Just my stream of consciousness again....

	-- Matt


On Aug 1, 2005, at 09:39, Jacob Smullyan wrote:

>  Dear followers of PyDO SVN:
>
>  In svn HEAD I"ve added two things that I hope will be timesavers,
>  ForeignKey and OneToMany:
>
>    class foo(PyDO):
>       fields=(Sequence("id"),
>               "name")
>
>    class bar(PyDO):
>      fields=(Sequence("id"),
>              "x",
>              "foo_id")
>
>      Foo=ForeignKey("foo_id", "id", foo)
>
>    # adding these outside the class body because of circularity
>    foo.getBar=OneToMany("id", "foo_id", bar)
>    # getBar takes getSome()-like methods
>    res=foo.getBar(LT(FIELD("x"), 500))
>    # the ForeignKey property is setable
>    res[0].Foo=foo.new(name="aardvark")
>
>
>  The purpose here is solely to avoid writing boilerplate; there is
>  nothing mysterious being done here that you couldn"t do before.  Both
>  ForeignKey and OneToMany deal with multi-column foreign keys as well
>  (just use tuples and make sure they are in the same order and have the
>  same length).
>
>  I added these to HEAD because 1) I needed them myself, and 2) there
>  are no backwards compatibility issues, so I felt I could justify it
>  without creating a branch, despite being in beta.  If people have very
>  different ideas about what could be done here and it looks like this
>  won"t reach stability soon, I can move it out to a branch.
>
>  A similar shortcut for many-to-many would be obvious to do and will
>  follow.
>
>  I didn"t see a single obvious pattern for 1-to-many mutator methods --
>  sometimes a setter that takes a sequence would make sense, sometimes
>  add()/remove() is the pattern you"d want to follow -- so I punted.  A
>  possibility would be, rather than directly returning an accessor
>  method from OneToMany, to return an object that would have get(),
>  set(), add(), and remove() methods.  I find that mildly irritating for
>  some reason, but maybe it is OK.
>
>  Any ideas?

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

iD8DBQFC+4L6nLpDzL5I7l8RAv/fAJ4t55Jd8ab2OeUPlwqb7ng8xaiaugCcC2/G
bMnenXEEBLE1SQt8qMHLCW0=
=eith
-----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