Sorry, I meant a different type of logger that does "filtering".

On Oct 6, 9:46 am, Jason Rogers <[email protected]> wrote:
> You could also introduce a different type of logger that does logging.
> A crude implementation is athttps://gist.github.com/1267367
>
> On Oct 5, 7:31 pm, Jeremy Evans <[email protected]> wrote:
>
>
>
>
>
>
>
> > On Oct 5, 1:52 pm, Peter van Hardenberg <[email protected]> wrote:
>
> > > On Wed, Oct 5, 2011 at 1:00 PM, Jeremy Evans <[email protected]> 
> > > wrote:
>
> > > > If you don't want to log the schema parsing information, the easier
> > > > solution is not to add a logger to the Database until after all your
> > > > model classes have been loaded.
>
> > > IIRC, at least on Postgres, the connection isn't established until the 
> > > first
> > > actual dataset executes a statement due to connection pooling logic.
>
> > That's true on most if not all Sequel adapters.  However, loading
> > model classes causes schema queries which will establish the
> > connection, so the approach I described should work in most cases.
> > There are other internal queries that Sequel runs (e.g. to get the
> > primary key for a table on PostgreSQL when inserting) that such an
> > approach will not hide, though.
>
> > Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en.

Reply via email to