Just tested if using LEP to serve the current paths to the documents is going
to work for me. It is still too slow when compared to retrieving the path
directly from a field in the DB.
Using LEP to get 17 paths on request from the web site takes 7-8
seconds.
Passing the paths from 4D fields serves the same 17 paths in less than
1 second.
The times are how long it takes a single HTTP request to get the document names
and paths from 4D and display the names in a list. The list of names in some
cases can be quite large.
I am using 4D v16.1 on a MacBook Pro running El Capitan.If I can get LEP to
work I'm am going to run the same tests on Windows.
John
> On May 16, 2017, at 10:58 AM, John Baughman <john...@hawaii.rr.com> wrote:
>
> I am rethinking what I am trying to achieve. The purpose of this exercise is
> to update file paths stored in 4D for thousands of architectural drawings
> when the folder containing all these nested drawings is moved to a different
> location locally or to a different machine.
>
> Ultimately the paths stored in 4D are sent to a web site for display in an
> end user’s browser.
>
> So currently the paths only need to be updated in 4D when the drawings folder
> is moved or reorganized.
>
> I am now thinking that maybe I should use LEP to get the current path when 4D
> gets the http request for the file, rather than relying on the path stored in
> 4D. A single call to LEP is almost instantaneous so this should work fine.
> This way I would not have to worry about where the end user puts or organizes
> the drawings as long as they are located on a drive that 4D can see.
>
> Ok, say I go this route, it should work great on the Mac, but what about
> windows. Is there a command similar to mdfind in the windows environment?
>
> John
>
>
>
>
>> On May 16, 2017, at 10:09 AM, John Baughman <john...@hawaii.rr.com> wrote:
>>
>> Are you all repeating the LEP in a loop? I am calling SysDoc_Find like this…
>>
>> vNewFolderPath:=Select folder("Select the the parent folder that contains
>> all documents... ";1)
>> ALL RECORDS([Document])
>> $size:=Records in selection([Document])
>> For ($i;1;$size)
>> GOTO SELECTED RECORD([Document];$i)
>> $documentToFind:=[Document]File_Name
>> $pathToDocumentFound:=SysDoc_Find ($documentToFind;vNewFolderPath)
>>
>> End for
>>
>> Do not know how to do a loop like this in the command line. what does it
>> look like?
>>
>> John
>>
>>> On May 16, 2017, at 9:45 AM, Lee Hinde via 4D_Tech <4d_tech@lists.4d.com>
>>> wrote:
>>>
>>> I’d second that. I just tried it in the command line on a folder with 5,144
>>> (nested) files and with almost 1,400 results the response was near instant.
>>>
>>> So, I tried this in 15.4 and Mac 10.12.5.
>>>
>>> Basically stripping the convert path stuff because I was passing in the
>>> full path and those commands messed it up. Also, unquoted the file name.
>>>
>>> But then point is, it was instant.
>>>
>>>
>>> //Method: SysDoc_Find
>>> C_TEXT($searchFor;$1;$searchIn;$2;$pathFound;$0)
>>> $searchFor:=$1
>>> $searchIn:=$2
>>>
>>> //$searchIn:=Convert path system to POSIX($searchIn)
>>> $_txt_OSASCRIPT:="mdfind -onlyin "+$searchIn+" -name "+$searchFor
>>> $_t_InputStream:=""
>>> $_t_OutputStream:=""
>>> LAUNCH EXTERNAL PROCESS($_txt_OSASCRIPT;$_t_InputStream;$pathFound)
>>>
>>> //If ($pathFound#"")
>>> //$pathFound:=Replace string(Convert path POSIX to
>>> system($pathFound);"\n";””)
>>>
>>> // //Note: This is the code I ran for my tests. It is not complete as LEP
>>> is actually returning a list of paths to all the documents found with the
>>> same name.
>>> // //For my test I knew that there would only be one path found so I
>>> eliminated anything unnecessary
>>> // //My SysDoc_Find method actually converts pathFound to a process array,
>>> and returns the first element in the array. The caller can then either use
>>> the returned path or the array.
>>> // //Also, be aware that $pathFound ends with a \n. So the last element of
>>> the array may need to be deleted. My text to array method returns an empty
>>> last element.
>>>
>>> //End if
>>> $0:=$pathFound
>>>
>>>> On May 16, 2017, at 12:32 PM, Jeffrey Kain via 4D_Tech
>>>> <4d_tech@lists.4d.com> wrote:
>>>>
>>>> Which version of 4D are you using? Some versions have a bug in LEP that
>>>> causes them to use 100% of the CPU when they are waiting for the result,
>>>> thus drastically slowing everything down.
>>>>
>>>> If you repeat it from the command line instead from inside 4D, what
>>>> happens?
>>>>
>>>> --
>>>> Jeffrey Kain
>>>> jeffrey.k...@gmail.com
>>>>
>>>>> On May 16, 2017, at 3:26 PM, John Baughman via 4D_Tech
>>>>> <4d_tech@lists.4d.com> wrote:
>>>>>
>>>>> Interestingly this is way slower than crawling through the directories.
>>>>> Using my SearchFolderContents_Jut method which I posted in my original
>>>>> message it takes about 35 seconds to find 526 documents in a folder where
>>>>> the documents are at most nested 3 folders deep. Using LEP to search the
>>>>> same 526 documents takes almost 3 minutes!
>>>>
>>>> **********************************************************************
>>>> 4D Internet Users Group (4D iNUG)
>>>> FAQ: http://lists.4d.com/faqnug.html
>>>> Archive: http://lists.4d.com/archives.html
>>>> Options: http://lists.4d.com/mailman/options/4d_tech
>>>> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
>>>> **********************************************************************
>>>
>>> **********************************************************************
>>> 4D Internet Users Group (4D iNUG)
>>> FAQ: http://lists.4d.com/faqnug.html
>>> Archive: http://lists.4d.com/archives.html
>>> Options: http://lists.4d.com/mailman/options/4d_tech
>>> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
>>> **********************************************************************
>>
>
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
