Is it me or is

quick

trying to be too clever? • I have a table called

smartmeters

• I have an entity called

SmartMeter.cfc

• I am using the

QuickService

• I have

property name="SmartMeterService" inject="quickService:SmartMeter"

in my handler's pseudo constructor • I'm calling

var smartMeters = SmartMeterService.all()

• And bang

Table 'smart_meters' doesn't exist

• WHAT? So it seems like

quick

said... Oooh, oooh, I can make two words out of "smartmeters" so I'll be helpful and snake case it for you even though your entity name actually matches exactly an existing table name, do you like what I did there! No thank you! I shouldn't really have to

component _table_='smartmeters' ...

my entity when there's already an exact match with a table, surely?

I always specify tablenames, keys etcetera in quick, but that’s because I don’t like the defaults, and prefer to have the exact names in my code. But you don’t have to do that. According to the docs the default is:

We don’t need to tell Quick what table name to use for our entity. By default, Quick uses the pluralized name of the component for the table name. That means for our

User

entity Quick will assume the table name is

users

. You can override this by specifying a

table

metadata attribute on the component.

I must admit that I used to specify my table names in the past but then I went all minimal and stopped stating the *$%^@ obvious in my code for default values. I get and appreciate the pluralisation of entity names to table names but don't snake_case it if I've done all the hard work to match the values as expected. I'm struggling to imagine the conversation that went along the lines of "_if we recognise a string as two words, let's stick an underscore between them even if the entity name matches the table name, that sounds like a good feature!_". Sorry, I'm grumpy because I wasted the whole of my Sunday afternoon trying to work out what was happening because I was a fool and had my dev error handling hiding all my messages 😳

I am coming from cborm and cform where I had to specify everything. Although I do like most of quick now, I certainly don’t like the automatic naming conventions, so I am happy I can specify my own names. There’s more where quick caused me headaches, for example by incorrectly converting some strings to dates, which can also be circumvented by explicitly naming datatypes in some cases. I am just surprised to see this snake casing. I never noticed it before, although I did contribute to some of the code.

My lineage is the same and in general I'm happy with the defaults, hence not repeating them, but this one bit me 🐍 on the bum!

I added a note now to the docs, which mentions this snake casing. Not visible yet because it is still in review.

Yes, I was going to add something but was going to wait until our American friends woke up and took a look at my rambling words.

I'm struggling to imagine the conversation

I'm not-- I'm sure the conversation happened in the context of a DB where the naming convention was snake case and the CFC naming convention was not 🤷 It probably seemed pretty useful at the time with the obvious work around that you could override the table name if you didn't like the default. Perhaps @elpete can just add a setting to disable the snake case assumption in automatic naming. I have yet to see two clients using the exact same DB naming conventions, so Eric is sort of darned if he does and darned if he doesn't because nothing is going to match every use case.

I get it as a fallback but not when I've made an effort to line the entity name up with the table name. Anyway, I appreciated the override and like I said, I was grumpy due to my other foolishness.

I’ve updated the docs to reflect the

snake_case

convention. I’m sorry it caused issues today, @richard.herbert. I was fairly certain it was in the docs already. In fact, I went to where I thought it was and read it and could hear “snake cased” in my head, but it definitely wasn’t there. @bdw429s is right that database naming conventions are the part of Quick that everyone disagrees with. 😉 In particular, I think the

snake_cased

table names are actually the last remnant from the early version of Quick where all columns were retrieved by default (you didn’t need to specify properties) and the relationship conventions also assumed

snake_case

. The relationship conventions changed to just be

camelCase

, but it looks like the table names stuck around. Again, sorry for the missing docs that contributed to a frustrating experience.

Hey, no worries, I appreciate the efforts you all put into developing and maintaining such a great set of tools and services for us. Like I said, my frustration was really around my foolishness to be hiding all error messages. I as soon as I turned on those messages I could see the issue and added the

table

attribute as Wil said. I think @wil-shiftinsert has submitted a doc's pr on the subject?

Yup. I took it, modified it a bit, and merged it already.

I tried to find it, but where are these snakes Eric? I searched for it, but maybe I am looking at some cached version?

Ah…it was only on the 5.0.0 beta docs. It’s on the 4.2 stable docs now.

Yes, it is there now 👍. I was really surprised I never noticed the snake casing in the code before 😮

(hijacking this a bit) - speaking of 5.0, is there a plan for when it will be out?

Probably ITB

Thank you both /cc @wil-shiftinsert @elpete