cause usually you want to retrieve metadata more than you need the actual contents. It makes you more **sure** when you have to select the entire content vs just the metadata attached. When you'll switch to storing the contents too on the table, that table can be partitioned and optimized further (some db don't handle well by default large binaries). Generally, every application now treats the uploads in an async way, so if there is any data attached is better to separate "roles" in different tables anyway. Having them separated leads to a "separation of concerns" in the first place, so your app would be less lenient to, e.g. retrieve the file contents and discard it without using it.
On Thursday, March 28, 2013 5:48:35 PM UTC+1, Lamps902 wrote: > > Thanks, niphlod and Anthony - some good suggestions and considerations > mentioned there. niphlod - can you clarify why you recommend using separate > tables specifically for large files (to prevent users from having to > re-upload large files when forms aren't accepted?)? The async idea sounds > pretty good, although it would require a pretty considerable rewrite of a > lot of the code I have... > > On Thursday, March 28, 2013 11:19:06 AM UTC-5, Niphlod wrote: >> >> It's a bad design choice using a single table with lots of fields plus an >> attachment (if the attachment is large). >> I always store attachments in a separate table. >> >> That being said, I don't think that keepvalues will do the trick, cause >> basically keepvalues sends back to the client the contents and prefills the >> field ... throwing the file back to the client doesn't **sound smart**. >> However, it's a chicken-and-egg problem.... let's say you want to upload a >> picture, you require the picture to have a tag, but the user forgets >> it..... in this case, retaining in some way the file can be done... >> But let's say you want the file to end with .txt only ..... the .exe file >> should be discarded at all. >> It's up to you to provide logic consistent with the workflow you want for >> your users ..... >> /me would provide an async upload, store the id on the session and let >> the user play with the remaining fields in a form. >> Everyday I'd prune all the attachments received with no "remaining >> fields" attached. >> >> On Thursday, March 28, 2013 5:08:24 PM UTC+1, Lamps902 wrote: >>> >>> When a form has errors, the value of an upload field is reset upon >>> submission. Is there a way to retain this value, or does this pretty much >>> have to be handled manually (i.e. by storing the value of the upload field >>> or by prompting the user to specify the file again)? >>> >> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
