[JBoss JIRA] (TEIID-4277) Infinispan Cache DSL translator: materialization incomplete results during view's loading
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4277?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4277:
------------------------------------
Determined that the issue is happening after a server restart.
> Infinispan Cache DSL translator: materialization incomplete results during view's loading
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4277
> URL: https://issues.jboss.org/browse/TEIID-4277
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.5
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Blocker
> Attachments: test.log
>
>
> When user tries to query materialized view in a moment when its loading is in progress, incomplete results are returned. The status of the view in corresponding status table is LOADING.
> Vdb used:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <vdb name="jdg-remote" version="1">
> <description>For testing of materialized views</description>
> <property name ="lib" value ="org.jboss.qe.jdg.pojos"></property>
> <model name="jdgSource">
> <source name="jdgSource" translator-name="jdg-override"
> connection-jndi-name="java:/jdg-mat-ds" />
> <metadata type="DDL"><![CDATA[
> CREATE FOREIGN TABLE CustomerReport(
> customerId integer not null OPTIONS (SEARCHABLE 'Searchable', NATIVE_TYPE 'int'),
> totalAmount integer,
> CONSTRAINT PK_ID PRIMARY KEY(customerId)
> ) OPTIONS (NAMEINSOURCE '${db.table.prefix}jdg-mat', UPDATABLE TRUE);]]>
> </metadata>
> </model>
> <model name="h2Source">
> <source name="h2Source" translator-name="h2" connection-jndi-name="java:/h2-ds" />
> </model>
> <model name="View" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW external_long_ttl (
> customerId integer NOT NULL,
> totalAmount integer
> ) OPTIONS (MATERIALIZED 'TRUE',
> MATERIALIZED_TABLE 'jdgSource.CustomerReport',
> "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
> "teiid_rel:MATVIEW_LOAD_SCRIPT" 'INSERT INTO jdgSource.CustomerReport(customerId,totalAmount) SELECT c.id AS customerId, CONVERT(SUM(o.amount),integer) AS totalAmount FROM DV_MATVIEWS_CUSTOMERS c INNER JOIN DV_MATVIEWS_ORDERS o ON c.id = o.customer_id GROUP BY c.id;',
> "teiid_rel:MATVIEW_STATUS_TABLE" 'h2Source.DB.PUBLIC.DV_MATVIEWS_STATUSTABLE',
> "teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute jdgSource.native(''truncate cache'');',
> "teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute jdgSource.native(''swap cache names'');',
> "teiid_rel:MATVIEW_ONERROR_ACTION" 'WAIT',
> "teiid_rel:MATVIEW_TTL" 10000
> )
> AS SELECT c.id AS customerId, CONVERT(SUM(o.amount),integer) AS totalAmount FROM DV_MATVIEWS_CUSTOMERS c INNER JOIN DV_MATVIEWS_ORDERS o ON c.id = o.customer_id GROUP BY c.id;
> ]]>
> </metadata>
> </model>
> <translator name="jdg-override" type="infinispan-cache-dsl">
> <property name="SupportsDirectQueryProcedure" value="true" />
> </translator>
> </vdb>
> {code}
> Resource-adapter used:
> {code:xml}
> <resource-adapter id="jdg-mat">
> <module slot="main" id="org.jboss.teiid.resource-adapter.infinispan.dsl"/>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.infinispan.dsl.InfinispanManagedConnectionFactory" jndi-name="java:/jdg-mat-ds" enabled="true" pool-name="jdg-mat">
> <config-property name="ProtobufDefinitionFile">
> /org/jboss/qe/jdg/remote/protobuf/CustomerReport.proto
> </config-property>
> <config-property name="AliasCacheName">
> ${db.table.prefix}jdg-alias
> </config-property>
> <config-property name="MessageMarshallers">
> org.jboss.qe.jdg.pojo.CustomerReport:org.jboss.qe.jdg.remote.marshaller.CustomerReportMarshaller
> </config-property>
> <config-property name="RemoteServerList">
> [remote-server-address]:11322
> </config-property>
> <config-property name="StagingCacheName">
> ${db.table.prefix}jdg-mat-stage
> </config-property>
> <config-property name="CacheTypeMap">
> ${db.table.prefix}jdg-mat:org.jboss.qe.jdg.pojo.CustomerReport;customerId
> </config-property>
> <config-property name="MessageDescriptor">
> org.jboss.qe.jdg.remote.protobuf.CustomerReport
> </config-property>
> <config-property name="Module">
> org.jboss.qe.jdg.pojos
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> {code}
> Datasource used (tables that the view queries):
> {code:xml}
> <xa-datasource jndi-name="java:/h2-ds" pool-name="h2-xa-ds" enabled="true">
> <xa-datasource-property name="URL">
> jdbc:h2:tcp://localhost:9292/db;TRACE_LEVEL_FILE=4
> </xa-datasource-property>
> <driver>h2</driver>
> <security>
> <user-name>sa</user-name>
> </security>
> </xa-datasource>
> {code}
> Query invoked to check current contents of materialized view:
> {code:sql}
> SELECT COUNT(*) FROM external_long_ttl;
> {code}
> And expected result is the same as count of DV_MATVIEWS_CUSTOMERS table from source h2Source. In my case 10.
> But when I print out the result I get all numbers from 0 to 10 . See attached log output (search for 'check-count:')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4311 at 7/5/16 1:42 AM:
------------------------------------------------------------
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.
> especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
{code}
createXADataSource=xa-data-source add --name={0} --driver-name={1} --jndi-name={2} {3} --xa-datasource-properties=[{4}]
{code}
* 0, 1, 2 - Required argument
* 3 - Optional argument
* 4 - at lease define 1 properties base on wildfly 10 datasource change.
{code}
public void createXADataSource(String deploymentName, final String driverName, final Properties properties)
{code}
0, 1, 2 come from deploymentName and driverName; 3 come from properties, the left properties will go into 4.
was (Author: kylin):
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.
> especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
{code}
createXADataSource=xa-data-source add --name={0} --driver-name={1} --jndi-name={2} {3} --xa-datasource-properties=[{4}]
{code}
* 0, 1, 2 - Required argument
* 3 - Optional argument
* 4 - at lease define 1 properties base on wildfly 10 datasource change.
> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
> Key: TEIID-4311
> URL: https://issues.jboss.org/browse/TEIID-4311
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.13.x
> Reporter: Prakash Jape
> Assignee: Kylin Soong
> Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4311 at 7/5/16 1:40 AM:
------------------------------------------------------------
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.
> especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
{code}
createXADataSource=xa-data-source add --name={0} --driver-name={1} --jndi-name={2} {3} --xa-datasource-properties=[{4}]
{code}
* 0, 1, 2 - Required argument
* 3 - Optional argument
* 4 - at lease define 1 properties base on wildfly 10 datasource change.
was (Author: kylin):
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.
> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
> Key: TEIID-4311
> URL: https://issues.jboss.org/browse/TEIID-4311
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.13.x
> Reporter: Prakash Jape
> Assignee: Kylin Soong
> Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4311 at 7/5/16 1:36 AM:
------------------------------------------------------------
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.
was (Author: kylin):
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic and execute it in runtime, BRMS use a file define business rules and use the rule in runtime to make some decision, even VDB use a file define table views and runtime query these pre-defined views.
> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
> Key: TEIID-4311
> URL: https://issues.jboss.org/browse/TEIID-4311
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.13.x
> Reporter: Prakash Jape
> Assignee: Kylin Soong
> Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4311:
------------------------------------
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.
Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}", driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}
An alternative is use "xa-data-source add" which like reference pull request.
> The CLI is simple enough to write in code and include template properties in-line and write readable code
>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as
http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite...
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic and execute it in runtime, BRMS use a file define business rules and use the rule in runtime to make some decision, even VDB use a file define table views and runtime query these pre-defined views.
> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
> Key: TEIID-4311
> URL: https://issues.jboss.org/browse/TEIID-4311
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.13.x
> Reporter: Prakash Jape
> Assignee: Kylin Soong
> Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4317) Always init translator capabilities
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4317?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4317.
-----------------------------------
Fix Version/s: 9.1
9.0.1
Resolution: Done
Changed in 9.1 to call init in start for all translators. Narrowed the scope for the 9.0.1 to just the jdbc translator.
> Always init translator capabilities
> -----------------------------------
>
> Key: TEIID-4317
> URL: https://issues.jboss.org/browse/TEIID-4317
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.5
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.1
>
>
> there is init logic on the impala, pg, and sqlserver translators that won't get run if the database version is explicitly set on the translator. Can it be changed to always run init logic?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4311:
-------------------------------------
Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do. I believe Teiid is one of them. In reality, Data Source class is POJO you set properties on it to create connection. It became some what of standard among drivers to have the property names I mentioned before. There may be lot more database specific properties, for those I was suggesting to "connection-properties" property.
The CLI is simple enough to write in code and include template properties in-line and write readable code. Although it is easy to use CommandContext, do not see much reason switch now, especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
Please re-write using above suggestions.
> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
> Key: TEIID-4311
> URL: https://issues.jboss.org/browse/TEIID-4311
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.13.x
> Reporter: Prakash Jape
> Assignee: Kylin Soong
> Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
