Thanks for the advice, Niphlod. I really should go read a good book on relational db design...
On Thursday, March 28, 2013 3:48:23 PM UTC-5, Niphlod wrote: > > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
