RE: Brandon's proposal

I agree Roberto.  I think Brandon's suggestion for a tag set is excellent.

RE: Caching, statements and time
 
Flushing a cache at a specific time is fine, because it can be done
synchronously.
As for the execute statement at times etc....I really don't think that
is within the scope of iBATIS.  It would introduce a scheduler and
background threads (both of which we don't have, or need now).

IMHO, a scheduler is an infrastructural component that is best kept
outside of any particular layer, because many layers are likely to
need it.  Furthermore, there's nothing worse than having multiple
schedulers in an architecture (I've been there).

The execute methods in SQL Maps are public.  They can easily be
registered with an external scheduler.

Cheers,
Clinton


On Wed, 2 Feb 2005 23:22:50 -0500, roberto <[EMAIL PROTECTED]> wrote:
> I like Brandon's approach of simple XML with some unintrusive EL.  I can't
> see how having a full-blown scripting language in a SqlMap file will help.
> Basically, I'd rather not debug a SQL Map file because of some
> pseudo-business logic that happened to be stored there...maybe if it was a
> BusinessMap file that had on the fly rule-checks (lol...not really).
> 
> I haven't worked with ANTLR, so unfortunately, I can't provide good feedback
> on that at the moment.
> 
> On another topic in the Java Roadmap, this caught my eye:
> 
> 2.3
>   Performance
>         - Cache dependency on other cache (flush-on-dependant)
>         - Flush cache at specific time (e.g. 22:30)
> 
> If that's in the plans, would "Execute statement at specific time" and
> "Execute statement after specified time period" be possible options?  I'm
> hesitant about "Execute statement dependency on other statement" since that
> ends up being so much like a database trigger (which can cause debugging
> headaches when you're working on a dysfunctional team!).
> 
> Roberto
> 
> > -----Original Message-----
> > From: Brandon Goodin [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 02, 2005 4:25 PM
> > To: [email protected]; [EMAIL PROTECTED]
> > Subject: Re: Prioritize the iBATIS Java Roadmap
> >
> > I posted my initial proposal. I look forward to hearing from the .NET
> > part of the team.
> >
> >
> > On Wed, 2 Feb 2005 13:52:23 -0700, Clinton Begin
> > <[EMAIL PROTECTED]> wrote:
> > > I'll maintain that improved dynamic SQL is big, and intrusive enough
> > > to warrant its own release.  That's not to say that we can't work on
> > > it any time...there is a pluggable architecture in place, it should be
> > > easy to isolate a dynamic SQL module.  In addition to the technical
> > > complexity, we seriously have to settle on a decision surrounding
> > > this.  Not the least of which is:  What about iBATIS.NET?  If we stray
> > > from XML and choose a predominantly Java-ish language to support
> > > (Velocity, Groovy etc.) there could be concerns around the uniformity
> > > and consistency of our product accross platforms.
> > >
> > > All of these decisions require collaboration.  I suggest we use our
> > > Wiki for such collaboration.  I've created a Improved Dynamic SQL
> > > Whiteboard on the Wiki to continue with the development of the ideas.
> > >
> > > http://wiki.apache.org/ibatis/Improved_20Dynamic_20SQL_20Whiteboard
> > >
> > > So, I'm all for a 2.2 release that's all about Dynamic SQL.  The plan
> > > I'll propose is below..
> > >
> > > Cheers,
> > > Clinton
> > >
> > > -------------------------
> > > 2.1 -- First Apache Release
> > >   Ease of Use
> > >       - <generate> tag for CRUD methods (as per iBATIS.NET)
> > >   Object Oriented
> > >       - <subclass> tag for inheritance support (as per iBATIS.NET)
> > >   Flexibility
> > >       - Constructor based results (not fields at this time)
> > >
> > > 2.2
> > >   Ease of Use
> > >       - Improved Dynamic SQL syntax/flexibility
> > >       - Pluggable SQL Scripting languages
> > >
> > > 2.3
> > >   Flexibility
> > >       - Field based results
> > >   Performance
> > >       - Cache dependency on other cache (flush-on-dependant)
> > >       - Flush cache at specific time (e.g. 22:30)
> > >   Database Support
> > >       - Save point support
> > >       - Add true autocommit support (mostly for SYBASE procs)
> > >
> > > 2.4
> > >   Flexibility
> > >       - Override/extend mapped statements (i.e. reuse SQL;
> > > overrides="statementName")
> > >   Ease of Use
> > >       - Improved configuration API and logging
> > > -------------------------
> > >
> > >
> > > On Wed, 2 Feb 2005 13:36:28 -0500, roberto <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > Just trying to keep this thread alive (or wake it back up)...
> > > >
> > > >
> > > >
> > > > To summarize, here is what it looks like with the given feedback:
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------
> > > >
> > > >                       Road Map
> > > >
> > > > ------------------------------------------------------------
> > > >
> > > >
> > > >
> > > > 2.1
> > > >
> > > >   Ease of Use
> > > >
> > > >       - <generate> tag for CRUD methods
> > > >
> > > >   Object Oriented
> > > >
> > > > -        Inheritance via selects or joins (same as groups)
> > > >
> > > >   Flexibility
> > > >
> > > >       - Constructor and field based results (CB: Move up from 2.2?)
> > > >
> > > >   Dynamic SQL
> > > >
> > > >       - Improved syntax/flexibility (BG)
> > > >
> > > >
> > > >
> > > > 2.2
> > > >
> > > >   Ease of Use
> > > >
> > > >       - Improved configuration API and logging
> > > >
> > > >       - Pluggable SQL Scripting languages (RR: related to 2.1 Dynamic
> > SQL?)
> > > >
> > > >   Flexibility
> > > >
> > > >       - Override/extend mapped statements (i.e. reuse SQL;
> > > >
> > > > overrides="statementName")
> > > >
> > > >       - Constructor and field based results (CB: Move up to 2.1?)
> > > >
> > > >   Performance
> > > >
> > > >       - Cache dependency on other cache (flush-on-dependant)
> > > >
> > > >       - Flush cache at specific time (e.g. 22:30)
> > > >
> > > >   Database Support
> > > >
> > > >       - Save point support
> > > >
> > > >       - Add true autocommit support (mostly for SYBASE procs)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  Roberto
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Brandon Goodin [mailto:[EMAIL PROTECTED]
> > > >
> > > > > Sent: Saturday, January 29, 2005 10:13 AM
> > > >
> > > > > To: [email protected]; [EMAIL PROTECTED]
> > > >
> > > > > Subject: Re: Prioritize the iBATIS Java Roadmap
> > > >
> > > > >
> > > >
> > > > > I thought we'd work on getting the Ease of Use moved into 2.1.
> > Either
> > > >
> > > > > that or see "improved dynamic sql" in 2.1.
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > > On Sat, 29 Jan 2005 01:53:29 -0700, Clinton Begin
> > > >
> > > > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > > IMHO, it's already prioritized based on user demand and alignment
> > with
> > > >
> > > > > > the features already in place in the .NET version.
> > > >
> > > > > >
> > > >
> > > > > > A couple from 2.2 may move up...like constructor mapped results.
> > > >
> > > > > >
> > > >
> > > > > > Cheers,
> > > >
> > > > > > Clinton
> > > >
> > > > > >
> > > >
> > > > > > On Sat, 29 Jan 2005 01:43:31 -0500, [EMAIL PROTECTED]
> > > >
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > > > Here's the content of road-map.txt:
> > > >
> > > > > > >
> > > >
> > > > > > > ------------------------------------------------------------
> > > >
> > > > > > >                       Road Map
> > > >
> > > > > > > ------------------------------------------------------------
> > > >
> > > > > > >
> > > >
> > > > > > > 2.1
> > > >
> > > > > > >   Ease of Use
> > > >
> > > > > > >       - <generate> tag for CRUD methods
> > > >
> > > > > > >   Object Oriented
> > > >
> > > > > > >       - Inheritance via selects or joins (same as groups)
> > > >
> > > > > > >
> > > >
> > > > > > > 2.2
> > > >
> > > > > > >   Ease of Use
> > > >
> > > > > > >       - Improved configuration API and logging
> > > >
> > > > > > >       - Pluggable SQL Scripting languages
> > > >
> > > > > > >   Flexibility
> > > >
> > > > > > >       - Override/extend mapped statements (i.e. reuse SQL;
> > > >
> > > > > > > overrides="statementName")
> > > >
> > > > > > >       - Constructor and field based results
> > > >
> > > > > > >   Performance
> > > >
> > > > > > >       - Cache dependency on other cache (flush-on-dependant)
> > > >
> > > > > > >       - Flush cache at specific time (e.g. 22:30)
> > > >
> > > > > > >   Database Support
> > > >
> > > > > > >       - Save point support
> > > >
> > > > > > >       - Add true autocommit support (mostly for SYBASE procs)
> > > >
> > > >
> > >
> 
>

Reply via email to