Wholy moly... The file system was definately NOT made to be a live data store. For one, disc IO is several orders of magnitude slower than memory IO. Maybe soon a memory/file system meld will revolutionize computing, be we are about 30 years behind this. Retrieve your data from disc and unpack it ... Then do the reverse ... You can even do this in a background thread (in chunks on idle) all the time... But do your data work from within vars and custom props. In the absence of native object inheritence handling in xtalk, it is tempting to use the file system's built in object tree (ontology) structure as an organizational tructure for data storage... But your question indiates a need to parse object heirarchies (a navigation algorithm) anyway, and once you have this its just as easy to use it to structure your data as use the file system for the same. Am i helping you here? It is sad that this level of data organization i not natively supported within xtalk (hint hint) but you have to roll your own... And that times every scripter = some serious waisted meat mips.
-----Original Message----- From: "Thierry" <[EMAIL PROTECTED]> To: "RevList" <use-revolution@lists.runrev.com> Sent: 1/16/2008 8:25 AM Subject: importing a bunch of files Hi, Another thread about kind of Database :-) For a specific project, I need to implement this: I have an arbitrary set of text files stored on the disk in an arbitrary numbers of directories, within a root one, ie: dirRoot/ dirRoot/f1 dirRoor/f2 dirRoot/dir2/f3 dirRoot/dir2/dir3/f4 dirRoot/dir4/f5 ....... When it comes to deliver the project, I want to import all theses files, and the tree organization inside a stack ( datas only stack ). I'm thinking of mapping each directory to a group; the first group would be named dirRoot, dir2 and dir4 would become groups named dir2 and dir4, children of the first group, dir3 a group inside dir2 group, etc... and for the files, importing them in custom properties of these groups with the same name as the original files. Let say it could be a hundred files or even more.... One extreme could be one group with a hundred properties, another one a hundred nested groups with one property for each group. Do you think this is realistic to do so, and what kind of pitfalls i can find on the way ? Another solution could be to create as many text fields as files, with each field named with the full path of the corresponding file..... ? Any hints or thoughts are welcome, before I jump into it. Regards, Thierry _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
