Cfinsert & cfupdate (and rename of cfscript to dbinsert and dbupdate)

language
1

I’d like to propose that cfinsert and cfupdate get an added attribute “fieldObject” this would allow the form scope to be replace by a structure of keys.

IMHO it would also be fitting to change insert and update tag related functions to dbinsert and dbupdate as the former are ambiguous and generic , the suggested names are more obvious.

the fieldlist attribute could then be used in conjunction with this object to limit fields, so basically the ‘fieldObject’ simply overrides

It would be a quick change, three lines of code (adding the parameter, adding the null reset, and adding a line to write over the form variable by chaing line 238)

Form form = pageContext.formScope();

to

Form form = fieldobject ? fieldObject : pageContext.formScope();

2 Likes
2

Just realised this has been depreciated, rather than improved ditching the ‘old’ form scope and just allowing any struct. It’s a killer tag/script functionality. (missed the community discussion on this??)

I’d rather see ORM and rest api functionality depreciated (both shouldn’t be core either - should be extensions) before the changed I suggested IN 2016…

Any chance this could be implemented INSTEAD of depreciating the two tags/functions?

Sure removing the reliance on the form scope, and replacing with a fields struct always made sense to me DECADES ago. But instead of removing the tags, how about we just make them the way THEY SHOULD have been done, making the tag super easy to use and giving back the joy of why we chose cfml in the first place.

3

I don’t mind still improving on them, but they will remain deprecated, just like isDefined is no longer recommended

which just means they are really not recommended anymore, backwards compat is important to us

no name change tho

PR with testcases are welcome

2 Likes
4

ORM was moved out to an extension quite a while ago.

5

I’ve created a ticket about allowing using a different scope / struct as the source for cfinsert and cfupdate

https://luceeserver.atlassian.net/browse/LDEV-5604

1 Like
6

Added to 7.0.0.232-SNAPSHOT

7

Speaking of decades ago, that’s how long it’s been since I used either of those tags, along with cfform, cfinput, etc. It’s so much better using cfscript and QueryExecute(). I can’t imagine updates to ancient deprecated tags being anything above absolute lowest priority.

3 Likes
8

100% agree, but it was a fun exercise and the idea made sense, I’d had the same idea when I wrote the testcases for them in the test suite, which was the first time I’d ever tried them, for all the reasons you describe.

plus they are slow as they have to read the table metadata each time and probably often the get implemented without proper security checks.

9

So you don’t use it so make it low priority, lets not start that game, I’ll put most of what you use on low priority as I dont use it…

10
  • so we can’t cache metadata lookups? not as if everything else is cached?
  • aren’t I talking about modernising this? we’re not talking about what is, but what should be. The whole concept of CFML is abstraction. We keep forgetting the whole point of this language sometimes.
  • I’d suggest most people assume the current db checks are ‘security’ (they are far from it’), security is barely worse with lack of validators, a list is a varchar? should we also get rid of queryAppend() ( added in v6 ) as that also doesn’t have security checks? #goosegander – queryAppend is bascially cfinsert for object queries?
  • Slow compared to what?
  • If you want to talk overhead, ORM brings overhead in multiple unwanted directions, maybe depreciate that too (should be optional extension anyway)
11

My point is simply that the Lucee community doesn’t have unlimited human resources, thus priorities must be established, and you are requesting changes to DEPRECATED features.

2 Likes
12

depreciated is a label :wink: takes 2 seconds to change that.

Also not saying this couldn’t be moved out of core to be an extension.

I think 90% of the functionality in default build should be extensions, so I’d find this no different if most people aren’t using it.

It neither makes it old or obsolete, just not used in it’s current state.

There is also a handful of test cases in github repo for lucee that use cfinsert, so they need to be replace also.

13

If you’ve checked the docs, I’ve removed the deprecated status.

That said, we ain’t going to be doing anymore work on these tags, but backwards compat is important, so they won’t be removed.

But they are really, really, really not recommended, because they are often going to be a dead end as soon as you hit an edge case and you need to convert to using cfquery / cfqueryparam, which is why they are considered bad practise.

Lucee provides the core building blocks for making applications, if you want to roll your own framework using the core functionality, i.e. cfdbinfo and cfquery caching and flushing metadata and all that jazz, go for it

As for QueryAppend, I assume you are just kinda trolling for the sake of it?

Leave QueryAppend alone, even tho I’d forgotten it exists!!!

2 Likes
14

wasn’t trolling, just was saying that if security was the ‘reason’ for getting rid of it, then we have ‘another problem’ to fix also :wink:

Thanks for at least considering my use case. #appreciated

2 Likes
15

A case in point to this, sticking a JSON formatted text with a ’ or even " into a MariaDB LONGTEXT will break the JSON return without using a cfqueryparam to insert it. Given I have been playing with Walmart and Amazon Catalog JSON Schema’s, there are times where they are “Quoting things” or using the ’ in their JSON returns and completely breaks deserializeJSON() because of it.

16

A case in point to this, sticking a JSON formatted text with a ’ or even " into a MariaDB LONGTEXT will break the JSON return without using a cfqueryparam to insert it.

is that using preserveSingleQuotes (or setting on or off)? Just interested.

And it’s beside the point anyway, a bug.