No announcement yet.
  • Filter
  • Time
Clear All
new posts

    5.1p Serverside DataImport - how to get DataSource instance to loop through

    Hi Isomorphic,

    I have a DataSource where I dynamically configure the uploadFieldName with a DynamicDSGenerator.
    This is working fine. I'm using the same DataSource serverside to periodically import eMails with a servlet.

    In the end, the servlet feeds the data to a DataImport instance via dataImport.importDataSourceRecords(emailContentReader, importDS);

    In order to translate csv->.ds.xml-fieldname as well I need to use a different overload with columnRemap-parameter. I assume this is what the serverside component of the BatchUploader does as well.

    My question is how do I get an instance of my Upload-DataSource where I can loop though the fields can create the columnRemap?
    ServerDataSourceImplementation warns that one should not use "new DataSource()". But how to get a DataSource then? On the serverside, there is no static DataSource.get().

    I'd call getFieldNames() and getField() on the instance to generate my map. How do I destroy the instance afterwards? Do I have to do anything in order not to leak memory?

    Thank you & Best regards

    That same doc tells you to use RPCManager.getDataSource().

    If you are in a situation where you do not have an RPCManager, use DataSourceManager.getDataSource(), but in this case you are responsible for later returning that DataSource instance (with RPCManager there is automatic cleanup at the end of the HTTP request).


      Hi Isomorphic,

      thanks for the pointer to DataSourceManager.getDataSource() - just the information I needed and great to see this use case is already covered.
      Follow up question:
      Yes I am in a situation where I don't have a RPCManager as I wget to a Servlet and start from there. I'm reusing DMIs that are usually hit from SmartGWT clientside requests.
      All these DMIs generate child requests like this:
      DSRequest childRequest = new DSRequest("otherDS", DataSource.OP_FETCH, request.getRPCManager());
      As request.getRPCManager() is null, these requests do not participate in a transaction or even have access to the original RequestContext/HttpServletRequest/HttpServletResponse, which brings other problems (e.g. no access to session variables). I have to manually prepare them like suggested by you here, which I currently do with a static method that gets the new request, the old request, a DSTransaction, the original HttpServletRequest and figures out from the original DSRequests settings what to apply.

      In the best case this adds a call to the static method after every new DSRequest.
      DSRequest childRequest = new DSRequest("childDS", ...);
      // prepare request
      Helper.prepareServerRequest(childRequest, originalRequest, servletRequest, servletResponse, dsTransaction); //newly added
      childRequest... //code as before
      DSResponse childResponse = childRequest.execute();
      This is code I'm just developing. Is this the correct way to handle this? Or is there some other way I could do this? I'm thinking of somehow getting my first request in the servlet to have a RPCManager - This would make the "new DSRequest("otherDS", DataSource.OP_FETCH, request.getRPCManager())" in child DMIs "just work".

      Thank you & Best regards


        This approach is fine, other than the obvious economy that your helper method could just create the DSRequest directly, rather than requiring two separate calls.


          Hi Isomorphic,

          thanks for the suggestion. I'll see if this would safe me LOC.
          Is "getting my first request in the servlet to have a RPCManager" possible? If not (which I assume), or not suggested best practice, it's also OK as the other way seems to be working fine. This is more a deeper understanding question.

          Best regards


            You can create an RPCManager in a servlet and then call processRPCTransaction() and you'll have an automatically managed transaction and all the usual features that you have when IDACall is used. If you never call processRPCTransaction(), and instead are running in the "standalone DataSource usage" style, then it's not valid to try to use an RPCManager with created DSRequests.


              Great, thank you. I will have a look at it!