[Isomorphic]

1. you were always at square one, as setting "sql" when you don't actually want "sql" isn't progress. Your attachment, which presumably is some kind of error message, didn't work.

2/3. once again: these criteria won't work unless the fields are declared

5. please read the fetchMissingValues docs: requests are sent with the PK of the current record as criteria, and you should return a record as usual. If you've implemented the "fetch" operation as described in the docs, this is no extra work - the PK is just ordinary criteria. You still haven't even indicated whether you see this request at all.

[jbrau01]

I don't want the "criteria" to come from the data, the fields, or the primary keys from within the datasource/listgrid. In both the Accounts and Users datasource request, I would like the "criteria" to come externally. I even marked the criteria data as Request* (RequestUserID, RequestStartDate,RequestEndDate,RequestManagerID).


I have read the fetchMissingValues and understand how the primary key functions in these requests. What I am trying to do is get the Users to load regardless of the data in the Accounts listgrid. When the grid loads I want both the Accounts Datasource:

AccountID , AccountName, UserID (FK)

and the users datasource:

UserID (PK) , UserName

to be loaded and have the framework display the UserName that is associated to each Account's UserID in a SelectItem/ComboBox. The request criteria for loading both the Accounts and Users is the same, and has no relationship to the Account fields, records, or primary key values. I can't use fetchMissingValues (I believe) because I am never instantiating a FormItem class, I am only specifying a

editorType="SelectItem"

in the accounts.ds.xml.


Thanks,

[Isomorphic]

As we've covered a few times, you must declare fields used as criteria in your DataSource, or the criteria will be ignored. It doesn't matter where the criteria are introduced: client-side, server-side etc, but there must be field declarations. And obviously, the declared field names must match the names of the criteria values.

As we've also covered a few times, fetchMissingValues is on by default, you do not need to turn it on. Have you even checked for whether there is a request being issued? We keep mentioning this, you seem to be ignoring it.

And finally, we still don't have any kind of diagnostics or error messages for what is going wrong when you are using (some of) the correct settings - serverType:"generic" for both DataSources. Server logs for any failing request are expected with the first report of an issue (see FAQ).

If you could pay a bit closer attention to what we're saying we'll have this resolved very quickly.

[jbrau01]

So, just to clarify, we are concluding that it is impossible to externally configure the criteria of a datasource request for the request of SelectItem values within a ListGridField? The data that gets supplied as criteria for this request (Users request) must come from the ListGrid records (Accounts data), via fields specified in the datasource XML definition (accounts.ds.xml) .



I found the below error message in the Developer Console which resulted in the "failure with no error message" popup:

XRP9:WARN:RPCManager:Server returned FAILURE with no error message performing operation 'accounts_fetch'. - response: {operationId: "accounts_fetch", clientContext: Obj, internalClientContext: Obj, context: Obj, transactionNum: 0, httpResponseCode: 200, httpResponseText: "//isc_RPCResponseStart-->[{affectedRows:..."[138], xmlHttpRequest: [object XMLHttpRequest], transport: "xmlHttpRequest", status: -1, clientOnly: undef, httpHeaders: Obj, isStructured: true, callbackArgs: null, results: Obj, affectedRows: 0, invalidateCache: false, isDSResponse: true, queueStatus: -1, data: null, startRow: 0, endRow: 0, totalRows: 0}


Despite this error message, however, I can also see within the Developer Console that the datasources are loading correctly (but nothing gets returned to the client, and the poup error message is displayed) :





Thanks,

[Isomorphic]

So, just to clarify, we are concluding that it is impossible to externally configure the criteria of a datasource request for the request of SelectItem values within a ListGridField? The data that gets supplied as criteria for this request (Users request) must come from the ListGrid records (Accounts data), via fields specified in the datasource XML definition (accounts.ds.xml) .

No, incorrect. We just told you:

As we've covered a few times, you must declare fields used as criteria in your DataSource, or the criteria will be ignored. It doesn't matter where the criteria are introduced: client-side, server-side etc, but there must be field declarations. And obviously, the declared field names must match the names of the criteria values.

We're not sure how to rephrase this to make it any clearer, so we'll just try to spell it all out with a lot of redundancy: you must have DataSourceField definitions in your DataSource for any fields that criteria are applied to, because criteria values that target field names that aren't declared in your DataSource will be ignored regardless of the source of the criteria. There is no need to define the criteria values themselves in the .ds.xml in some way. The criteria can be established via any of the APIs in SmartClient where you are allowed to define criteria (for example: passing it to fetchData(), modifying the data in transformRequest, setCriteria(), other ways). But once those criteria are actually used to do filtering, if there is no field definition in the DataSource for the fields that the criteria apply to, criteria with no field definitions will be ignored.

As far as this request that is erroring out, we *still* don't have server logs for this, which again is the first thing you need to share when you have a request failing on the server.

[jbrau01]

There are no server logs, if I had seen anything I would have provided them immediately. As you can see from the Developer Console screenshot, the server seems to be building the datasources and the requests behind the scenes fine, but then returns status = -1 and displays:

Server return FAILURE with no error message performing 'accounts_fetch'

I am unable to gather any logs besides the RPCManager:Server warning that I already provided you.

So since you are being so clear and redundant, I will take you at your word literally. When you say :

you must have DataSourceField definitions in your DataSource for any fields that criteria are applied to

and this is what my criteria looks like (for the Accounts fetchData):

criteria.addCriteria("RequestUserID", 123);
criteria.addCriteria("RequestStartDate","2017-01-01");
criteria.addCriteria("RequestEndDate","2017-01-31");
criteria.addCriteria("RequestManagerID",567);

then I should add the below fields to my accounts.ds.xml to get the above criteria to pass through to the Users datasource request (users.ds.xml) , even though I am never explicitly calling fetchData() on the users datasource:

<field name="RequestUserID"     type="integer"      hidden="true"    />
<field name="RequestStartDate"  type="text"         hidden="true"    />
<field name="RequestEndDate"    type="text"         hidden="true"    />
<field name="RequestManagerID"  type="integer"      hidden="true"    />

You also said:

for example: passing it to fetchData(), modifying the data in transformRequest, setCriteria(), other ways

But these are all explicit ways of configuring the criteria/request from the Java code. I am not instantiating or configuring the Users datasource from the Java code. The Users datasource request is simply being called during the Accounts dataource request.

If either of us are still confused, I think we may both benefit from you just taking a look at the sample project I created this on. Telling me how the framework is supposed to work clearly isn't helping either of us. If you truly understand what I'm trying to accomplish, then all you need to do is look at the code and XML from my first post, all of the relevant details are there. If you need more information, I can gladly supply the sample project.


Thanks,

[Isomorphic]

Wow, you have no logs at all? This explains a lot.

The default setup is to log a great deal of key diagnostic information through log4j (covered here and here in the docs). Somehow you disabled this, so you have basically been flying blind. You need to get these logs back as the first thing you do; there is no point in doing anything else until you have normal diagnostics, so you can see what the error is and how it happened.

As far as the criteria and field definitions, yes, you need those field definitions on the Accounts DataSource or the criteria will be ignored. As a matter of an in-memory join configured via includeFrom, those criteria would never be applied to the Users DataSource, since that request is by PK only, so the exact records needed are already identified. The only criteria that would ever be applied to an included field would be criteria applied to the included field itself (eg UserName).

[jbrau01]

Oh sorry! I didn't have the XML configured correctly in my test app. I attached a logfile that includes a stacktrace. The error is :

[com.isomorphic.servlet.RequestContext] - dsRequest.execute() failed: java.lang.UnsupportedOperationException

Let me know if this helps!

Thanks,

[jbrau01]

I've made some progress by analyzing the logs. I changed a List to an ArrayList and that error went away.

Regarding 0 rows being returned, I had to add the "criteria" values ( RequestUserID, RequestStartDate , RequestEndDate , RequestManagerID ) to each Account object before it was returned, and the data began showing up. I believe this has something to do with a manual sort/filter function:

 
 DSRequest.applyManualFilterAndSort :   
 [B]In manual filter, we found filter values for which there is no corresponding field in the first record of the resultset.   This may be expected, but it may be an indicator that you are not fetching all required fields - manual (ie, non-SQL) sort and filter can only work  if you actually fetch the criteria and sortBy fields from the database. Affected fields:[/B] RequestUserID, RequestStartDate, RequestEndDate, RequestManagerID

But I'm not sure why adding the request criteria values into the return object was a necessary step.

Still outstanding is getting these criteria values into the fetchUsers function. But according to your most recent reply, this is impossible and the only criteria ever present will be the UserID.

Thanks,

[Isomorphic]

If you don't add the criteria values to the records, then the records do not match the criteria, right? What other way could this work? The point of criteria is to eliminate records that do not match.

Right, criteria targeting fields of the Accounts DataSource would not be applied to the Users DataSource, just as they would not be applied in a join, which is what includeFrom is simulating in this mode. We still can't make any sense of this expectation, other than to say that maybe your confusion is coming from the fact that you are using a property that does a join, but you don't want a join, but rather something totally different. Or perhaps the field you have declared as a PK in the Users DataSource isn't really a PK.

[jbrau01]

I think this is where the confusion came from. It seems that in most of the datasource examples, "Criteria" gets treated as a filtering mechanism, it pretty much becomes the "where" clause in the SQL statement. You specify the field values as criteria, and they get applied to the result set to filter out the specific values you are looking for.

This is not how we have been using the "criteria" objects, combined with serverType="generic". We use generic because our database structure is very complicated and we utilize stored procedures heavily for the web interfaces, there isn't any dynamic SQL generation. The criteria (in the way we are using them) are inputs to these stored procedures, they have nothing to do with the actual field values related to the result set, they are simply inputs to a function.


This may not be the correct approach, but it is how we have been using it for some time now, and it has worked fine until this relational issue came up. Maybe you could suggest another way of accomplishing this? Is there any way to get input parameters into these data source requests, that have no relation to the result objects themselves?

[Isomorphic]

As we keep saying: the criteria will not work unless you declare the criteria fields as DataSourceFields

It doesn't matter if these are not fields that values can be saved to; the fields can be marked hidden or be marked canEdit:false or canSave:false so that they don't appear in forms and grids, but the field definition is needed so that we know the type of the field, which affects how filtering is performed, what editors are used if you build a search form for inputting criteria values, etc.

However, note that:

1. this isn't going to cause the criteria you supply to get passed to the Users DataSource in your includeFrom usage, because that's not how a join works, and includeFrom performs a join

2. once you've declared the criteria, your criteria values will kick in for client-side filtering too, as they should, and that means the records delivered to the client will have to include values that match the applied criteria. If these "criteria" values are really totally implicit as far as the UI, and never edited by end users, you can avoid this by introducing them at a later phase of processing, eg, introduce them to the DSRequest on the server-side via a DMI.

[jbrau01]

Yes I understand, I just clarified where the confusion came from.

Now, I am asking for alternative methods to supply input parameters to the Users datasource that have no relation to the Users result set. Do you know if this is possible with my current configuration?

Thanks,

[Blama]

Now, I am asking for alternative methods to supply input parameters to the Users datasource that have no relation to the Users result set. Do you know if this is possible with my current configuration?

If this is about the SelectItem used as editor in the ListGrid, just see my post#2. You can configure the SelectItem in maaaany ways, but need to do so in Java.
Additionally, if it is something static, perhaps you can to it in .ds.xml in the fetch operation binding with criteria or as suggested by Isomorphic in #27 in the DMI.

Best regards
Blama

[Isomorphic]

There are lots of ways to modify the criteria at different phases, as we've covered already, and there are also ways to supply non-criteria inputs (like passing them as HTTP parameters outside of criteria).

However, it's not possible to recommend a particular approach without knowing what these "inputs" mean.

For example: if the idea is that the current user should only be able to see certain entries from the Users DataSource, then you probably want to have the Users DataSource pick up the inputs from the session (since it would be a security hole to have them passed from the client) and the fact that those inputs are applied would be an internal detail of the Users DataSource; they wouldn't appear as normal criteria at all.

Totally different approaches might be appropriate if they do not represent security constraints; it depends on how often they change (eg do they change at all during the session?), whether the end user can edit them in a particular grid view (because in this case client-side filtering might have value), etc.