| Re: Ignoring Case on directories [message #171199 is a reply to message #171192] |
Wed, 29 December 2010 13:14   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 12/29/2010 12:31 AM, jwcarlton wrote:
> On Dec 28, 11:00 pm, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>> On 12/28/2010 8:13 PM, jwcarlton wrote:
>>
>>
>>
>>> On Dec 28, 5:39 pm, Captain Paralytic<paul_laut...@yahoo.com> wrote:
>>>> On Dec 28, 8:33 pm, jwcarlton<jwcarl...@gmail.com> wrote:
>>
>>>> > I think that the answer to this is "no", but I thought I'd ask :-)
>>
>>>> > I'm wanting to open a file where the directory path is given by the
>>>> > user. For example:
>>
>>>> > if (is_file("/path/to/" . $_GET['directory'] . "/file.txt"))
>>>> > $example = FILE("/path/to/" . $_GET['directory'] . "/file.txt");
>>
>>>> > else
>>>> > // return error
>>
>>>> > // please ignore any typos; I just typed this up here for the example
>>
>>>> > The thing is, the directory path could be, say, /path/to/SomeDirectory/
>>>> > file.txt, but the user could enter "somedirectory"; in which case,
>>>> > they would get the error.
>>
>>>> > Currently, I keep all of the directory names in a MySQL database, then
>>>> > before opening file.txt, I search for the directory in MySQL (which is
>>>> > case insensitive), then load the path based on the name in the
>>>> > database instead of what's given. But during peak hours, this method
>>>> > can result in several hundred MySQL queries per minute.
>>
>>>> > Before this, I just used opendir to load all of the directories into
>>>> > an array on the fly, then did a case insensitive search through the
>>>> > array. But, when I started having 90,000 directories (30,000 in 3
>>>> > separate parent directories), this was considerably slower than using
>>>> > MySQL.
>>
>>>> > So, the MySQL search works, but the question is, can PHP do a
>>>> > directory lookup that's case insensitive; and, preferably, return the
>>>> > case-correct directory name?
>>
>>>> A few hundred MySQL queries a minute. What's the problwm with that?
>>
>>>> And if you have the directories in a database, why aren't you
>>>> presenting them to the user to select as Jerry suggested.
>>
>>>> And if there reall are good reasons for not doing a mere few hundreds
>>>> of queries aa minute, or offering a list of direcories to select from,
>>>> why not just make them all lower case in the first place?
>>
>>>> If feels like you are trying to find a way to fix a very poor design.
>>>> The best way to do that is to change the design to something decent.
>>
>>> Naturally, this isn't the only script running queries. My average
>>> Apache processes per day is around 500 (although this week, the
>>> average is over 600).
>>
>>> I don't think the "why" is terribly relevant to the thread, but the
>>> logic is that the directories represent usernames of registered users.
>>> In addition to other features, this includes the ability for one user
>>> to send a message to another user. Now, they DO have the option of
>>> clicking on that person's username, which resolves the case issue, but
>>> I also have the option for them to simply enter the recipient's
>>> username... which is where I am trying to correct the case. It would
>>> be pointless to force them to choose a username from a list of
>>> 90,000+.
>>
>>> If I could do it over, I would have each of these directories created
>>> in lowercase by default. But unfortunately, this system dates back for
>>> about 10 years, and at the time, I had no clue that I would have so
>>> many users (I remember celebrating when we hit 500). One day, I'll
>>> probably go through and revise the entire thing, but for now, I'm
>>> simply trying to find a faster way to find the correct case for the
>>> username.
>>
>>> Robert, you're correct that this is running on Linux, so yeah, the
>>> system itself is case sensitive. I was hoping that something like
>>> realpath() or pathinfo() would return a case-corrected directory, but
>>> neither of those do it.
>>
>>> Jerry, do you mean to do something other than using opendir to grab
>>> all of the directory names, then sorting through them to find a match?
>>> This turned out to be uber-slow:
>>
>>> $dir = opendir("/path/to/1/"); // 30k directories
>>> array_push($dir, opendir("/path/to/2/")); // 30k directories
>>> array_push($dir, opendir("/path/to/3/")); // between 20k and 30k
>>> directories
>>
>>> foreach ($dir as $key) {
>>> if (strtolower($key) == strtolower($_GET['directory']))
>>> $found_directory = $key;
>>> }
>>
>>> That's just a sample typed up to show the logic, of course, so please
>>> ignore any typos.
>>
>> I was considering stricmp() - but if you've got 30K directories, you've
>> got more problems than that. You need to look at your architecture.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> What would you suggest as a better way to handle an unlimited number
> of folders that contain an unlimited number of messages, as well as
> additional files that may be unique to that user (an "ignore list",
> personalized settings, etc)?
>
> The current system creates a directory for each user, then text files
> within that directory for each "folder", and additional text files for
> settings, etc. I originally based this on how the server stores email,
> and the only real limitation I had was when I hit 32,000 directories
> (then quickly discovered that there's a default limit to the number of
> directories allowed).
>
> I don't know how I could accomplish this in a database. Creating a new
> table for each user seems ridiculous, but what's the alternative? A
> column for each "folder" wouldn't work, since each user can create new
> folders for themselves.
I would store it all in a database. No need for a table for each user
or a column for each folder. A column for the user and another column
for the type of data comes to mind.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]