[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #22099] Enhancement proposal: SQL-like interface to Find

From: Richard Neill
Subject: [bug #22099] Enhancement proposal: SQL-like interface to Find
Date: Thu, 24 Jan 2008 04:28:51 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (Ubuntu-feisty)


                 Summary: Enhancement proposal: SQL-like interface to Find
                 Project: findutils
            Submitted by: richardneill
            Submitted on: Thursday 24/01/08 at 04:28
                Category: find
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Richard Neill
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None
           Fixed Release: None



Here's an idea which suddenly struck me today. I was considering creating a
small database as a way to help track certain files. Of course, that's what a
filesystem *is* (even more so, if Reiser4 happens). So, it's a bit redundant
to use a database. On the other hand, SQL is a very nice language for this
sort of query. Hence my idea: implement an sql interface to find. 

An example of how this might work is the following:

find --sql "SELECT * FROM directory WHERE NAME ILIKE '%abc&' AND SIZE > 15 MB
 AND (date > 2007-12-30 or date < 2005-01-01) AND MIMETYPE == 'x/ogg' AND
METADATA Contains 'xyz'"

This would basically consist of:
  i) a simple parser to convert between sql-like syntax, and the native
syntax used by find

 ii) some extra criteria implemented, such as 
      - match MIME-type  (should be easy, use `file`)
      - match (regex) CONTENTS  (grep through the file)
      - match (regex) part of CONTENTS (eg search the first 512
          and last 512 bytes for a string) 
      - METADATA   (for certain files, eg jpg, ogg, mp3...
          look at the id3,jhead etc tags)
      - SUBDIRECTORY DEPTH == n   (eg max of 2 subdirs deep)

 (iii) it's only necessary to support SELECT, since other operations (DELETE
etc) can be done as normal by the exec{} function.

I think this way of doing file searches, by scanning rather than indexing is
quite useful for a certain category of workloads on modern hardware. Also, it
would be really useful to be able to find based on a few more criteria.

Anyway, just an idea - feel free to use it, or ignore it.

HTH, and thanks for everything - Richard



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]