on removing build-dao-methods

[Marijn Haverbeke]

Hi Marco,

Though I'm happy to do baseline maintenance and merging of patches for
the project, I don't have a lot of time to invest in it. And sweeping
changes would need extremely careful review, and would no doubt cause
further issues for other people. So I have to say no, in my
distribution, we're down to minimal, super-conservative maintenance.
Feel free to start a fork.

Best,
Marijn

On Thu, Jan 30, 2014 at 12:33 AM, Marco Baringer <mb at bese.it> wrote:
>
> i'd like to replace build-dao-methods with a set of slots on the
> dao-class instance, a common root in the class hierarchy (which would be
> dao-object) and a set of methods specialized on dao-object. before i do
> the work i want to make sure the patch won't be rejected on principle.
>
> my main problem with build-dao-methods is that it generates a new,
> distinct, method on the generic functions for every dao-class instance.
> when you have a lot of dao-class instances it becomes difficult to
> figure out which methods are auto generated and which are 'real' and may
> do something different than the standard methods (and implementing these
> non standard methods requires rewriting a lot of the code in
> build-dao-methods since call-next-method doesn't actually do
> anything).
>
> another problem, though i haven't actually had this problem in practice,
> is that build-dao-methods defines shared-initialize :after method on the
> given class to call fetch-defaults; this makes it impossible for me to
> define my own shared-initialize :after method to perform whatever extra
> initialization i may have. i can imagine a work around to this issue by
> defining the dao-class and then subclassing it to get the actual
> functionality i need, or call fetch-defaults myself, but being able to
> just define an :after method and have things Just Work(TM) seems
> simpler.
>
> there are a few things the build-dao-methods does that, i think, i can
> maintain using just the plain old mop:
>
> 1. only defining update-dao and upsert-dao when the class has value
>    fields. by inspecting the class at compute-class-precedence-list time
>    we can inject either dao-value-object or dao-key-only-object and then
>    define the update/upsert-dao methods on dao-value-object and not
>    dao-key-only-object.
>
>    fwiw i think these methods should be defined for all dao objects;
>    just because all the slots of the object are its primary key doesn't
>    mean that changing one of those slots doesn't make sense (this can
>    happen in practice when working with relation tables whose columns
>    are all foreign keys and to preserve uniqueness of the relation the
>    primary key consists of all (usually 2) columns).
>
> 2. the methods defined by build-dao-methods close over a set of
>    precomputed values (column names and sql templates). by storing these
>    values in the class instance directly we still avoid recomputing them
>    every time the method is called and gain the ability to, easily,
>    inspect their values at run time for debugging purposes.
>
> the one thing build-dao-methods does that i can't maintain is the lack
> of a common root class for all dao-class instances (in order for the
> various update/get/upsert/insert dao methods to get called there will
> need to be a dao-object in the hierarchy somewhere). the dao-object
> class can be injected in dao-class instance's precedence-list via
> compute-class-precedence-list, so there wouldn't be any changes required
> to user code; i don't really see this as an issue.
>
> i would also need to add in a dependency on closer-mop. i could imagine
> just cut 'n pasting the, relatively limited, parts of closer-mop we'd
> actually be using, and that would keep postmodern's dependencies to what
> they are today, but that seems like a bad thing to do.
>
> since this is a substantial change to how the dao methods are created
> i'd like to make sure that there aren't any objects to it (philosophical
> or technical) before actually making the change and submitting the pull
> request.
>
> thanks,
> --
> -marco
>