Announcement

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

    Using SQL Connector for fetching data

    Hi,

    We are trying to use inbuilt ds, SQL Connector, for populating the ListGrid component (eliminating the need of hibernate support), by using serverType="sql" and using tableName="abc" in our ds.xml.

    Server.properties is used to specify the database connection parameters .

    GWT Version is : 2.7
    SmartGWT version : 6.1 power


    As per the above defined environment, we had few queries:

    1. As in Hibernate, we have an option to specify transient variables which can be used in UI but not for persistence. How can the same be achieved in SQL Connector scenario. We want that
    we maintain certain properties which are not associated with the tables but are used on the UI.

    2. We need to support complex JOINS in our case. As the SLQConnector approach has support for where/orderby/groupby clause, does it also support LEFT/RIGHT OUTER JOINS?
    If no, then how should we implement a complex query using JOINS in this approach?

    3. As we understand, in inbuiltDS approach, GWT creates a new DB connection using the properties specified in server.properties.
    Can we somehow use a predefined DATASOURCE/CONNECTION POOL in an application, so that the builtinDS uses the connection from this poll instead of creating it's own?

    4. We were trying to write a custom SQL, JOINing multiple tables and fetching data. How do we map the SELECT column list from different tables, with the field list we define in the ds.xml file?

    5. In the case of custom query, as mentioned in point 4, how will the update operation work?

    Thanks,
    Sidharth.

    #2
    Hi sidharth1917,

    I can give you my best practices:

    1) This might help
    2) The same docs as 1), search for foreignKey, joinType (outer=Left outer join) and includeFrom
    3) It's pooled automatically, see these docs.
    4) Not sure here, but I think having matching column name and name-attributes in your <field> is enough.
    5) You need to be more specific here, updates always go to one table. As long as your joins are only 1:n lookups, you don't need 4) and 2) will handle everything just fine.

    Best regards
    Blama

    Comment


      #3
      sidharth escalated this question as though it was unanswered, so this is just a post to officially say: Blama answered your question correctly, including where he asked you to be more specific.

      Comment

      Working...
      X