[JBoss JIRA] (TEIID-5449) Infinispan: Update Infinispan translator to 9.3 version
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5449?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5449:
------------------------------------
Now that its confirmed that the marshaller is defined at the table level and there isn't a reason to support multiple structures for the same entity, and after removing the thread based marshaller, is there anything else to consider?
> Infinispan: Update Infinispan translator to 9.3 version
> -------------------------------------------------------
>
> Key: TEIID-5449
> URL: https://issues.jboss.org/browse/TEIID-5449
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 11.0
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Priority: Major
> Fix For: 11.2
>
>
> Two changes observed
> - The new cache create API changed, the old has been deprecated
> - cache.get(key) now became Async operation, that means Thread Based serialization context no longer works. This needs to be removed, but there seem to be no better alternatives to support the Async threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5449) Infinispan: Update Infinispan translator to 9.3 version
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5449?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-5449 at 10/4/18 9:25 AM:
-------------------------------------------------------------
In a production environment, once a cache has data, it isn't going to change without a migration. So if a VDB has a related cache table updated, it must be backwards compatible. Also, the caveat being, there can't be 2 entities with the same name. Therefore, 2 simultaneous connections would not fail. However, in a development environment, there's possibility for collisions when 2 people would be developing using the same entity name, regardless if they are trying to use the same cache or not. The collision could occur due to the wrong marshaller instance being used (last in wins).
Issue: the marshaller registration uses a single instance, so the last one registered for the same entity name will be used.
Could use MashallerProvider , but as indicated, reads are async, so the thread based model doesn't work.
was (Author: van.halbert):
In a production environment, once a cache has data, it isn't going to change without a migration. So if a VDB has a related cache table updated, it must be backwards compatible. Therefore, 2 simultaneous connections would not fail. However, in a development environment, there's possibility for collisions when 2 people would be using the same entity name.
> Infinispan: Update Infinispan translator to 9.3 version
> -------------------------------------------------------
>
> Key: TEIID-5449
> URL: https://issues.jboss.org/browse/TEIID-5449
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 11.0
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Priority: Major
> Fix For: 11.2
>
>
> Two changes observed
> - The new cache create API changed, the old has been deprecated
> - cache.get(key) now became Async operation, that means Thread Based serialization context no longer works. This needs to be removed, but there seem to be no better alternatives to support the Async threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-4251) Built in support for Postgres DB as materialization target
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4251:
---------------------------------------
Obviously we'd also have to run the various create index / constraint statements as needed as well.
> Built in support for Postgres DB as materialization target
> ----------------------------------------------------------
>
> Key: TEIID-4251
> URL: https://issues.jboss.org/browse/TEIID-4251
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> If Postgres database is available along with install or assumed that it is available, then some of the materialization task can be automated, like
> - Creation of a common STATUS table
> - Creation of the materilization targets (create views on dbms)
> - On load, on undeploy and load scripts for all the materialization views
> We need to device a way this to be pluggable, such that based on success of this, we can provide additional support for other sources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-4251) Built in support for Postgres DB as materialization target
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4251:
---------------------------------------
This would be further predicated on having a materialization target database created for each service that needs materialization.
In pg sql terms this looks like the initialization steps:
{code}
CREATE EXTENSION postgres_fdw;
CREATE SERVER teiid_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'TEIID_SERVICE_HOST', port 'TEIID_SERVICE_PORT', dbname 'VDB'); -- note, this performs no initial validation
CREATE USER MAPPING FOR pg_user
SERVER teiid_server
OPTIONS (user 'TEIID_SECRET_USER', password 'TEIID_SECRET_PASSWORD');
{code}
Then for each materialized view we would have the initialization script (or new logic for):
{code}
IMPORT FOREIGN SCHEMA remote_schema
LIMIT TO (xxx)
FROM SERVER teiid_server
INTO public;
CREATE MATERIALIZED VIEW xxx_mat AS SELECT * FROM xxx;
{code}
Now on the postgresql instance there would be a materialized view xxx_mat.
Locally the teiid materialized view just needs pointed to xxx_mat on the pg source with our mat view management disabled.
The materialized view can be refreshed via REFRESH MATERIALIZED VIEW - which would require new new logic.
This approach does not allow for the more advanced refresh strategies, but that is probably ok from an initial release perspective.
> Built in support for Postgres DB as materialization target
> ----------------------------------------------------------
>
> Key: TEIID-4251
> URL: https://issues.jboss.org/browse/TEIID-4251
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> If Postgres database is available along with install or assumed that it is available, then some of the materialization task can be automated, like
> - Creation of a common STATUS table
> - Creation of the materilization targets (create views on dbms)
> - On load, on undeploy and load scripts for all the materialization views
> We need to device a way this to be pluggable, such that based on success of this, we can provide additional support for other sources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-4251) Built in support for Postgres DB as materialization target
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4251:
---------------------------------------
I'm going to investigate inverting this model. At least for snapshot with the option for full snapshot refresh we could use a pg materialized view rather than a Teiid one. We would need a fdw pointed from pg to Teiid, which should work OTB using the pg protocol.
> Built in support for Postgres DB as materialization target
> ----------------------------------------------------------
>
> Key: TEIID-4251
> URL: https://issues.jboss.org/browse/TEIID-4251
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> If Postgres database is available along with install or assumed that it is available, then some of the materialization task can be automated, like
> - Creation of a common STATUS table
> - Creation of the materilization targets (create views on dbms)
> - On load, on undeploy and load scripts for all the materialization views
> We need to device a way this to be pluggable, such that based on success of this, we can provide additional support for other sources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-4251) Built in support for Postgres DB as materialization target
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ]
Work on TEIID-4251 started by Steven Hawkins.
---------------------------------------------
> Built in support for Postgres DB as materialization target
> ----------------------------------------------------------
>
> Key: TEIID-4251
> URL: https://issues.jboss.org/browse/TEIID-4251
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> If Postgres database is available along with install or assumed that it is available, then some of the materialization task can be automated, like
> - Creation of a common STATUS table
> - Creation of the materilization targets (create views on dbms)
> - On load, on undeploy and load scripts for all the materialization views
> We need to device a way this to be pluggable, such that based on success of this, we can provide additional support for other sources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5449) Infinispan: Update Infinispan translator to 9.3 version
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5449?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5449:
------------------------------------
In a production environment, once a cache has data, it isn't going to change without a migration. So if a VDB has a related cache table updated, it must be backwards compatible. Therefore, 2 simultaneous connections would not fail. However, in a development environment, there's possibility for collisions when 2 people would be using the same entity name.
> Infinispan: Update Infinispan translator to 9.3 version
> -------------------------------------------------------
>
> Key: TEIID-5449
> URL: https://issues.jboss.org/browse/TEIID-5449
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 11.0
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Priority: Major
> Fix For: 11.2
>
>
> Two changes observed
> - The new cache create API changed, the old has been deprecated
> - cache.get(key) now became Async operation, that means Thread Based serialization context no longer works. This needs to be removed, but there seem to be no better alternatives to support the Async threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5496) archetype docs imply that they are published every release
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5496?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5496.
-----------------------------------
Resolution: Done
Settled on just changing the version number to 10.0.0 for now. These will seldom be released, so it doesn't seem to necessitate a lot of process.
> archetype docs imply that they are published every release
> ----------------------------------------------------------
>
> Key: TEIID-5496
> URL: https://issues.jboss.org/browse/TEIID-5496
> Project: Teiid
> Issue Type: Bug
> Components: Tools
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> The dev docs related to archetypes are parameterized to imply that a version is available corresponding to every release - however we have released them only sporadically. We should do one of:
> - use a different versioning scheme as to not imply a close coupling
> - add the release of the archetypes to the teiid release process
> And in general we need to update to point the docs to maven central rather than the jboss repository.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months