Thread

Please make sure that you nail the terminology before instituting this new approach to releases.

‘Nightly build’, ‘developer build’, ‘beta’, ‘tip’. Which is it? We only need one name for these type of releases, consistently applied so there is never any confusion. I’m not sure what a ‘tip’ is in this context. My preference is for calling them a ‘dev build’ - or similar - i.e. ‘not for production’.

I like the sound of this new approach. I think it’s going to be a big improvement. Keep up the good work.

Please make sure that you nail the terminology before instituting this new approach to releases.

‘Nightly build’, ‘developer build’, ‘beta’, ‘tip’. Which is it? We only need one name for these type of releases, consistently applied so there is never any confusion. I’m not sure what a ‘tip’ is in this context. My preference is for calling them a ‘dev build’ - or similar - i.e. ‘not for production’.

I like the sound of this new approach. I think it’s going to be a big improvement. Keep up the good work.

Internally we refer to it as the “tip” release because that’s how the concept was introduced to us. But I totally agree that’s an unhelpful label for it.

I like your suggestion for just calling it what it is, a dev release. We’ll make sure it has clear, consistent terminology when its officially introduced and doc’d.

Excellent. Thank you Leslie.

First of all I’m not sure if I like the idea of storing metadata in the database. (I was having this discussion with a few developers on twitter but having it here instead so more people can join in.)

My concerns are the increase in database size after sync.  Take one of my client projects.  It’s a property website with over 4000 uploaded files to date.  Mixture of JPG, PNG, GIF, PDF, DOC and SWF…

I also don’t see the point of having metadata in a table IMHO.  Maybe I’m missing the whole point I dunno…

However on another subject, when will there be better XSS filtering?  I’ve had some issues in 2.1.3 with various PDF’s and DOC’s file uploading failing. After some investigation and help from other forum members, the issue was down to how these files were generated and in my case they were generated using InDesign.  The mine types were not the same as PDF’s generated using Adobe Acrobat.  A quick fix for this was to turn off XSS filtering to allow uploading…which makes feeling un-eased.

Storing file metadata in the database is the best solution, I’m surprised this wasn’t done from the start to be honest - anyway, it won’t take up much space either. Don’t worry about it :p

Why is it the best solution?  Not explaining doesn’t help our community?

Telling us it won’t take up much space and not to worry isn’t an answer either!

It’s the best solution for efficiency, and it is what is done when one creates a mediabank/mediamanager (something the file manager is starting to resemble). Storing the file type, file size, etc. (metadata) in the database makes sense, as it’s not going to change (unless you replace the file, in which case it can be updated in the db) and you can query the database to find out the info you’d like to display instead of looking it up on each file each time you’d like to display it. I guess you can think of it sort of like a cache.

Storing file-type information about your clients’ 4000 files for instance will add something like 12 kilobytes to your database.

it was mentioned in Robin’s post a little earlier - although in short:

There are a number of advantages- most having to do w/searching/sorting once we have the ability to add more metadata.  With large directories, something as simple as paginating through them became clunky.  That would have been enough right there.

I tend to agree - the added flexibility this will provide will be helpful, especially for addons interacting with existing files and making it easier… Hopefully you see what i mean there?
Also the amount stored will be very minor in physical size - compare a single “file row” to say an entry in your blog - the blog post in size will be many times the size. Note we are storing the file info and not the actual file in the db.

I think this is also in response to “missing gallery” feature removed from EE1. With these details in a db and the TBC categories, etc, they will be able to create easy gallery function.

Thanks for clearing this up guys!  😊

What happens to the metadata if a new file is uploaded via FTP, or an existing file is replaced with another file via FTP?

These things happen, particularly when batch uploading lots of images on new sites, so I’d worry about this metadata getting out of sync.

Would there be an updating script running behind the scenes (an EE cron running every so often, for example) to check and keep things in sync?

I am pretty sure i read there was a sync button for this.

I am pretty sure i read there was a sync button for this.

That’d sort that then, thanks. 😊

I just want to confirm something

A simple ‘Synchronization’ on the File Upload Preferences page allows you to have all files in that directory imported into the database

You are not intending to import the files themselves into the database are you? Just the metadata I must assume. We have sites with many GB of files, no way this can get stored in MySQL efficiently.

If my assumption is correct, perhaps updating the blog post about this with a clearer definition is in order.

Thanks!

I just want to confirm something

A simple ‘Synchronization’ on the File Upload Preferences page allows you to have all files in that directory imported into the database

You are not intending to import the files themselves into the database are you? Just the metadata I must assume. We have sites with many GB of files, no way this can get stored in MySQL efficiently.

If my assumption is correct, perhaps updating the blog post about this with a clearer definition is in order.

Thanks!

And to be clear- it’s only the metadata that’s stored in the db, not the files themselves.

I did read the posts, honest. Obviously just not well enough, either that or the coffee hasn’t sunk in yet.

Thanks danieljohnbarnes for repeating the clarification.