[edulid]

Hi Isomorphic

as you see in this thread, I solved this issue by refactoring my code, such that no (fake) myField was necessary.
But if this would not be possible, i.e. if I need a (fake) myField, which approach would be the correct one? Approach 1, 2 or 3? And please take a look at the issues with each approach. No approach seems perfect, that's why I need your recommendation for next time.

[Isomorphic]

You need customFields if you want our the generated SQL to include the custom field in both the select and where clauses. If you just want to write the SQL yourself, you still need the field declaration, but you should just set customSQL="true" and do not use the customFields property.

[edulid]

Hi Isomorphic

interesting, this approach is the same as my original approach, with the difference that in your approach you declare the field while I don't declare it.
In the example, you suggest to use:

<DataSource ID="minimalTestcase" serverType="sql" tableName="minimalTestcase">
    <fields>
        <field name="FAKECOLUMN" type="text" customSQL="true" />
        <field name="f_id" type="integer" primaryKey="true" />
        <field name="f_lastname" type="text" />
        <field name="f_firstname" type="text" />
    </fields>

    <operationBindings>

        <operationBinding operationType="fetch">
            <whereClause><![CDATA[
              $advancedCriteria.FAKECOLUMN = 'abc' and ($defaultWhereClause)
           ]]></whereClause>
        </operationBinding>

    </operationBindings>

</DataSource>

which is generating

SELECT minimalTestcase.f_id, minimalTestcase.f_lastname, minimalTestcase.f_firstname FROM minimalTestcase WHERE
      'abc' = 'abc' and (('1'='1'))

This seems correct.
My original approach was:

<DataSource ID="minimalTestcase" serverType="sql" tableName="minimalTestcase">
    <fields>
        <field name="f_id" type="integer" primaryKey="true" />
        <field name="f_lastname" type="text" />
        <field name="f_firstname" type="text" />
    </fields>

    <operationBindings>

        <operationBinding operationType="fetch">
            <whereClause><![CDATA[
              $advancedCriteria.FAKECOLUMN = 'abc' and ($defaultWhereClause)
           ]]></whereClause>
        </operationBinding>

    </operationBindings>

</DataSource>

which is generating the same SQL.

So my question is:

If you just want to write the SQL yourself, you still need the field declaration

why do I need the field declaration? Not declaring it causes the same behavior. Is this a bug or is it intended ?
And why do you recommend to declare the field although it is not being used (because of the customSQL="true" and the lack of customFields="FAKECOLUMN") ?

[Isomorphic]

The field declaration gives us type information about the data, which is key for non-text fields, and is also required in some cases for serialization between browser and server.