From enaeher at gmail.com  Fri Feb 28 01:13:19 2014
From: enaeher at gmail.com (Eli Naeher)
Date: Thu, 27 Feb 2014 19:13:19 -0600
Subject: S-SQL and nested joins -- correct version
Message-ID: <CAJVWyAyP_+5vsjJQqi-7z=ogS7vTjUjt2Tm=CX5xHBgJBKyoLA@mail.gmail.com>

Hello,

My apologies, I sent my previous email by mistake before I'd finished
composing it. Here is the completed email:

Is there an S-SQL expression which will produce nested join expressions
like this one:

select * from table_1
  inner join table_2
    inner join table_3 on table_2.c = table_3.d
  on table_1.a = test_2.b;

(This form is described in section 7.2.1.1 of the Postgres documentation,
which says, "Joins of all types can be chained together or nested: either
or both T1 and T2 can be joined tables.")

I know I can do this:

(:select '* :from 'table-1
               :inner-join 'table-2 :on (:= 'table-1.a 'table-2.b)
               :inner-join 'table-3 :on (:= 'table-2.c 'table-3.d))

which produces a chained join expression:

(SELECT * FROM table_1
  INNER JOIN table_2 ON (table_1.a = table_2.b) INNER JOIN table_3 ON
(table_2.c = table_3.d))

However, these chained join expressions behave differently than nested ones
when mixing different types of joins (inner with outer, etc.), and I need
the behavior of the nested expression. I tried this:

(:select '* :from 'table-1
                 :inner-join 'table-2
                 :inner-join 'table-3 :on (:= 'table-2.c 'table-3.d)
                 :on (:= 'table-1.a 'table-2.b))

But it produces the error "Incorrect join form in select."

Am I missing the correct syntax, or is this unsupported right now?

Thank you,
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140227/acf36fd7/attachment.html>

From marijnh at gmail.com  Thu Feb  6 10:43:09 2014
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 6 Feb 2014 11:43:09 +0100
Subject: on removing build-dao-methods
In-Reply-To: <87bnyujrby.fsf@locaine.bese.it>
References: <87bnyujrby.fsf@locaine.bese.it>
Message-ID: <CAJnHWXvxRkgg-Q56REKOAwPGeNckXBLgstevNWPLz4aKwMAtzQ@mail.gmail.com>

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
>


From marijnh at gmail.com  Fri Feb 28 08:00:13 2014
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 28 Feb 2014 09:00:13 +0100
Subject: S-SQL and nested joins -- correct version
In-Reply-To: <CAJVWyAyP_+5vsjJQqi-7z=ogS7vTjUjt2Tm=CX5xHBgJBKyoLA@mail.gmail.com>
References: <CAJVWyAyP_+5vsjJQqi-7z=ogS7vTjUjt2Tm=CX5xHBgJBKyoLA@mail.gmail.com>
Message-ID: <CAJnHWXten7G41E04zu_ejDevw7nnZU+T2nPHnQadO4H5r=mvYg@mail.gmail.com>

Hi Eli,

I don't believe this is supported right now. Take a look at the code
that parses joins, if you want to be sure.

Best,
Marijn

On Fri, Feb 28, 2014 at 2:13 AM, Eli Naeher <enaeher at gmail.com> wrote:
> Hello,
>
> My apologies, I sent my previous email by mistake before I'd finished
> composing it. Here is the completed email:
>
> Is there an S-SQL expression which will produce nested join expressions like
> this one:
>
> select * from table_1
>   inner join table_2
>     inner join table_3 on table_2.c = table_3.d
>   on table_1.a = test_2.b;
>
> (This form is described in section 7.2.1.1 of the Postgres documentation,
> which says, "Joins of all types can be chained together or nested: either or
> both T1 and T2 can be joined tables.")
>
> I know I can do this:
>
> (:select '* :from 'table-1
>                :inner-join 'table-2 :on (:= 'table-1.a 'table-2.b)
>                :inner-join 'table-3 :on (:= 'table-2.c 'table-3.d))
>
> which produces a chained join expression:
>
> (SELECT * FROM table_1
>   INNER JOIN table_2 ON (table_1.a = table_2.b) INNER JOIN table_3 ON
> (table_2.c = table_3.d))
>
> However, these chained join expressions behave differently than nested ones
> when mixing different types of joins (inner with outer, etc.), and I need
> the behavior of the nested expression. I tried this:
>
> (:select '* :from 'table-1
>                  :inner-join 'table-2
>                  :inner-join 'table-3 :on (:= 'table-2.c 'table-3.d)
>                  :on (:= 'table-1.a 'table-2.b))
>
> But it produces the error "Incorrect join form in select."
>
> Am I missing the correct syntax, or is this unsupported right now?
>
> Thank you,
> -Eli
>
>


From enaeher at gmail.com  Fri Feb 28 01:07:54 2014
From: enaeher at gmail.com (Eli Naeher)
Date: Thu, 27 Feb 2014 19:07:54 -0600
Subject: S-SQL and nested joins
Message-ID: <CAJVWyAw1Mtjx2=oEk3XWO9BthG866ktVP0T4WX96Anava-1vRA@mail.gmail.com>

Hello,

Is there an S-SQL expression which will produce nested join expressions
like this one:

select * from table_1
  inner join table_2
    inner join table_3 on table_2.c = table_3.d
on table_1.a = test_2.b;

I know I can do this:

(:select '* :from 'table-1
               :inner-join 'table-2 :on (:= 'table-1.a 'table-2.b)
               :inner-join 'table-3 :on (:= 'table-2.c 'table-3.d))

which produces a chained join expression:

(SELECT * FROM table_1
  INNER JOIN table_2 ON (table_1.a = table_2.b) INNER JOIN table_3 ON
(table_2.c = table_3.d))

However, these chained join expressions behave differently than nested ones
when mixing different types of joins, and I need the behavior of the nested
expression. I tried this:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140227/ba8008c9/attachment.html>