I found all of these answers to a question I had:
Store pictures as files or in the database for a web app?
Storing images in SQL Server?
To Do or Not to Do: Store Images in a Database
And the last one links to even more versions of the same question. They typically have the same answer, suggesting to use a file system, then store the address in a data base. When they say "file system", do they mean store it in the folders that you use to make the website?
The way I've been learning to make websites, there's the "views" folder that has all the layouts, then there's the "public" folder that stores your css and js files. Then I have a line of code in the app so I don't have to type public all the time when I'm linking to my css files or js files. So would I store the images in there? With it's own folder and maybe a folder for each user? What happens when there's a lot of users and a lot of pictures?
Or should the pictures go somewhere else entirely?
I've done my best to find the answer on my own, but "file system" is such a generic term, I can't find the specific answer.
Yes, filesystem means to put them as files alongside the files that your website consists of.
Generally, there are a couple good practices to follow when doing so:
Put them in some folder that's dedicated to user data, not to the same folder you put your website's core files
Generate artificial file names (UUIDs or database-generated IDs) for them instead of using the original file names to avoid name collisions
If you expect a lot of files, on some filesystems it may be a good practice to create a level of subdirectories to limit number of items in each directory
It might be a good idea (depending on your use case) to forbid direct access to this folder with user data through plain HTML
Instead read the files and output them through your script
This is required if the files are not all public (if any authorization is needed to see them)
Related
I’m designing a custom file format. It will be either a monolith file or a folder with smaller files. It’s a rather large file in total and there is no need to load everything into memory at once. It would make it also slower than necessary. One of the file(s) may or may not be database file. Running SQL queries would be useful.
The user can have many such files. The user might want to share files with others even if it takes some time to up/download it.
Conceptually I run into issues with shared network folders, Dropbox, iCloud, etc. Such services can lead to sync issues if the file is not loaded entirely in memory or the database file can get corrupted.
One solution is to prohibit storing the file on such services. Either by using a user/library folder or forcing the user to pick a local folder.
Using a folder in library means recreating a file navigation system like Finder. It limits the choice of the user as well in where the files end up. Limiting the location to a local folder seems the better choice.
Is there a way to programmatically detect if a folder is local?
I would like to know if it is possible under MacOS to store "information" about some files, but not the files themselves? In essence, what I would like is to off-load certain large files from many of my projects to external drives/machines, but still retain the ability to get information about those off-loaded files when I look into the project directory for listing and information about its contents. I understand that what I am asking is not supported by the FS by default, but is there any third-party framework under which this is possible?
How do I decide which of my application's files go in Program Files (FOLDERID_ProgramFilesX64) and which go in ProgramData? (FOLDERID_ProgramData)? I don't understand what the reason is for splitting up my application's fixed files into these two categories or how I should decide which file goes in what.
For example - image files which my application displays, are they "program" or "data"?
Is there any problem with just putting everything under one or the other?
The application is installed for All Users and has no user-specific configuration files or data.
Program Files is for executables and other static files that came as part of the installation. ProgramData is for user-agnostic data generated during execution such as shared cache, shared databases, shared settings, shared preferences, etc. User-specific data goes in the AppData folder. Note that these are for non-user-visible data. User-visible data belongs in the documents folder (or music, video, custom sibling folder, etc.).
Please see Special Folders and Custom Folders for a detailed explanation. Note that the terminology used varies slightly between the name used in the documentation here, the name of the folder, and the name used by various enumerations used to get these paths from the system.
We are migrating our APP to Win7. The program generates log files to help us support and also saves a number of dictionary files and settings files that are useful for the user though the user will rarely if ever actually want to interact with the files outside of our application. They can though because they are csv files. I built the first run through with using the APPDATA\LOCAL\OURAPPLICATION folder as the destination. Now I am wondering if it should be PROGRAMDATA\OURAPPLICATION.
I actually think the first choice is better because it seems that everything I have scanned suggests that the PROGRAMDATA folder should be considered untouchable by the user but as I am not a programmer I am not sure.
I hope this is the right place to ask this question
The key point to consider is what the scope of the data is. If you are storing data that is associated with a specific user then you should use APPDATA and if you are storing data that is global to your program then you should use PROGRAMDATA.
Both APPDATA and PROGRAMDATA are hidden folders so the intent is for users not to be poking around in there (not that they couldn't if they wanted to).
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.