I have to agree with Herman.  When WebLink was first acquired by ISC, and during the period 1996-2000, we were demonstrating things that no other web tech at the time could do.  Chris's Event Broker technology, originally released as a Java-based technology that ran in the browser, preceded and delivered what much later became known as Ajax.  I remember during that time John Bertoglio, then a non-ISC user web guy who discovered what we were doing, telling me that in his estimation, we had a lead of between 5 and 8 years over what the rest of the industry was doing.   We did try to lead the horse to water and all that, but hey...

The difference is described in full in these two documents:

https://github.com/robtweed/global_storage/blob/master/Subscripts.md

https://github.com/robtweed/global_storage/blob/master/Leaf_Nodes.md

It's not a good idea to store files in the DB that you'll simply be reading back in full. The main issue you'll suffer from if you do hold them in the database (which nobody else seems to have picked up on)  is that you'll needlessly flush/replace global buffers every time you read them back (the bigger the files, the worse this will be).  Global buffers are one of the keys to performance.  

Save the files and files and use the database to store their filepaths as data and indices.

No disrespect to what you've created, but I have to say I'm always amazed and dismayed at how complex the Java community always seem to manage to make even the simplest of tasks - Spring/Hibernate is a classic example of making a crazy mountain out of what should technically be a very simple mole-hill.

By comparison, take a look at mgweb-server: https://github.com/robtweed/mgweb-server  and its underlying mg_web interface (https://github.com/chrisemunt/mg_web) for probably the thinnest (and therefore the most performant) and simplest way possible of delivering REST services using IRIS.  

Awaiting my app/repo to be approved and then I'll submit it to the competition...

Rob

if you're a JavaScript/Node.js developer, you can use the QEWD-JSdb abstractions of IRIS: 

- Document database

- Persistent JavaScript Objects

- Redis-like Lists

- Redis-like key/object store

- Persistent XML DOM (with XPath querying)

See: https://github.com/robtweed/qewd-starter-kit-iris-networked

Take the introductory tutorial:

https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

and then delve into the other database models:

- https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

A whole world of multi-model opportunities to explore for this competition!

Notice, by the way, the hefty performance penalty incurred by the SQL/Class option compared with the low-level ObjectScript functions ($extract and $translate).  

Wot, read documentation?? ;-)

Results running IRIS Container on Raspberry Pi 4 (4Gb RAM):

$e() only   1.279893

$tr()       1.281999

$e()+$zd()  1.470656

SQL/class   66.405927

I didn't include the SQL/static in my test on the RPi.

Comparison with IRIS on a Windows 10 i7 based Intel NUC machine:

$e() only   .14742
$tr()       .185998
$e()+$zd()  .182579
SQL/class   11.305143

Mind you, the NUC cost about 15 times that of the RPi :-)

Anyway, based on a combination of the performance and coolness of technique, the $tr() one gets my vote!

Wow, how have I not known this trick after all these years? :-)