Re: Non-physical delete... again

From: Andrey Razumovsky (razumovsky.andre..mail.com)
Date: Thu Jun 04 2009 - 08:07:41 EDT

  • Next message: Michael Gentry: "Board Report"

    Seems we have same questions in second feature I wanted to implement -
    qualifiers for DbEntities. Should they work for EJBQLs too? As far as I can
    tell after looking at the code, current EJBQL doesn't use ObjEntity
    qualifiers.
    I can't think of anything better than implementing DbEntity qualifier as
    simple string that will be ANDed with WHERE clauses for SELECT and JOIN
    tables. This way we won't be able to handle any difference between different
    DBMS. We just don't have "DB-based" expressions... Maybe you have better
    ideas..?

    Thanks,
    Andrey

    2009/6/3 Andrus Adamchik <andru..bjectstyle.org>

    >
    > On Jun 3, 2009, at 4:12 PM, Andrey Razumovsky wrote:
    >
    >>
    >>> Let's first decide which approach above we'll be using (1. intercept on
    >>> commit or 2. intercept of anything "delete").
    >>>
    >>>
    >> I see. What implemented now is "1.5 - intercept of anything
    >> DeleteBatchQuery". This might be okay if we plan #2 someday. Actually I
    >> want
    >> this feature right now, and changing EJBQL nature might be tricky. So I
    >> suggest we either end with #1 or commit current code, which is little part
    >> of #2.
    >>
    >
    > I suggest going with #1 then.
    >
    >
    > Looking at this one more time, I agree. This is irrelevant for approach
    >>> #1,
    >>> but for #2 I think we can achieve what we need with a DataNode bound
    >>> SQLActionVisitor, which allows to process all types of queries in a
    >>> generic
    >>> fashion (see below my notes on EJBQL).
    >>>
    >>>
    >> The most common SQLActionVisitor is JdbcActionBuilder and it cannot
    >> contain
    >> reference to DataNode by design, as said before.
    >>
    >
    > I meant this in a general sense. Your strategy class can have an anonymous
    > inner class implementing SQLActionVisitor or something like that. Anyways,
    > this is not applicable for #1 ... I think.
    >
    > Andrus
    >



    This archive was generated by hypermail 2.0.0 : Thu Jun 04 2009 - 08:08:15 EDT