[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3627:
------------------------------------
And the LT is not being sent to JDG and so Teiid handles it correctly. It would seem that the CompareCriteriaOrdered capability needs to be changed (disabled) to false so that on equality is passed to JDG for processing and all others (LT, LTE, GT, GTE) are handled in Teiid until JDG can fix their issue. And
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3627:
------------------------------------
The LTE is failing in JDG. What's being built by the JDG and its FilterConditionContext is:
AttributeCondition{isNegated=false, attributePath='stringNum', operatorAndArgument=LteOperator{argument=-22}}
and from the filter is created the query that is sent to JDG, for which returns zero results.
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3621) HBase translator - UPDATE statement requires primary key
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3621?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3621:
------------------------------------
> or only add the pk if it's missing and it's defined on the table
Do you mean only add document that define a pk if want execute the UPDATE, right? After some investigation, I think documents is enough for this issue.
> HBase translator - UPDATE statement requires primary key
> --------------------------------------------------------
>
> Key: TEIID-3621
> URL: https://issues.jboss.org/browse/TEIID-3621
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: Hbase: 1.1.1
> Phoenix: 4.5.0-HBase-1.1
> Reporter: Juraj Duráni
> Assignee: Kylin Soong
>
> The HBase translator requires table to have a primary key defined. Is the PK really needed? If the table has no PK defined, then all columns are PK. E.g. query *UPDATE hbase.SmallA SET StringNum = '555' WHERE hbase.SmallA.StringNum IS NULL* is translated as *UPSERT INTO smalla (stringnum, intkey) SELECT '555', smalla.intkey FROM smalla WHERE smalla.stringnum IS NULL* (intkey is PK). Teiid can simply add all columns (except those defined in 'SET').
> Yes, I know that HBase requires the PK to be defined, but what happen if a user decide to change PK in VDB [1]? It could be a problem whether PK is in VDB defined or not.
> I suggest to add a hbase-translator-specific execution property which define PK in the source table and remove AssertionError [2].
> [1]
> *HBase table:* create table mytable(id integer primary key, nickname varchar(1))
> *Teiid table:* create table mytable(id integer, username varchar(1) primary key)
> Both, id and username, are valid PK (artificial/natural).
> [2]
> https://github.com/teiid/teiid/blob/master/connectors/translator-hbase/sr...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3634) Issues with cloning on several language objects
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3634:
-------------------------------------
Summary: Issues with cloning on several language objects
Key: TEIID-3634
URL: https://issues.jboss.org/browse/TEIID-3634
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.7
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.12
TextTable and ObjectTable have fields that are not cloned and AggregateSymbol cannot be cloned in some circumstances if not resolved.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3633) Metadata exceptions don't provide the table name
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3633:
-------------------------------------
Summary: Metadata exceptions don't provide the table name
Key: TEIID-3633
URL: https://issues.jboss.org/browse/TEIID-3633
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Affects Versions: 8.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.12
Exceptions for an invalid name or assigning columns to a key don't provide the table name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3629) Teiid DDL columns options for Salesforce column have wrong name for "Calculated" property
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-3629?page=com.atlassian.jira.plugin... ]
Barry LaFond reassigned TEIID-3629:
-----------------------------------
Assignee: (was: Barry LaFond)
> Teiid DDL columns options for Salesforce column have wrong name for "Calculated" property
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-3629
> URL: https://issues.jboss.org/browse/TEIID-3629
> Project: Teiid
> Issue Type: Bug
> Reporter: Andrej Šmigala
> Priority: Minor
> Attachments: sfDDL.ddl
>
>
> Back in 2014, Teiid & Teiid Designer synched our Salesforce constants/extension properties to facilitate DDL import. However, it appears that the teiid_sf:calculated constant wasn't converted properly to *teiid_sf:Calculated*. https://github.com/teiid/teiid/commit/88781c220e1afc79c889cfc5d7c1c3e5d8e...
> I'm able to import the attached DDL if I change *teiid_sf:calculated* to *teiid_sf:Calculated*.
> The following is logged in the error log multiple times when importing Salesforce from Teiid Connection. The imported model appears to work ok (tried previewing a couple tables).
> {quote}
> java.lang.Exception: The property definition "salesforce:calculated" could not be found.
> at org.teiid.designer.core.extension.EmfModelObjectExtensionAssistant.setPropertyValue(EmfModelObjectExtensionAssistant.java:485)
> at org.teiid.designer.ddl.importer.node.EmfModelGenerator.setPropertyValue(EmfModelGenerator.java:1203)
> at org.teiid.designer.ddl.importer.node.EmfModelGenerator.processExtensionProperties(EmfModelGenerator.java:1110)
> at org.teiid.designer.ddl.importer.node.EmfModelGenerator.execute(EmfModelGenerator.java:219)
> at org.teiid.designer.ddl.importer.DdlImporter.save(DdlImporter.java:324)
> at org.teiid.designer.teiidimporter.ui.wizard.TeiidImportManager$2.run(TeiidImportManager.java:802)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:466)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:374)
> at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:527)
> at org.teiid.designer.teiidimporter.ui.wizard.TeiidImportManager.saveUsingDdlDiffReport(TeiidImportManager.java:795)
> at org.teiid.designer.teiidimporter.ui.wizard.TeiidImportWizard.finish(TeiidImportWizard.java:197)
> at org.teiid.designer.ui.common.wizard.AbstractWizard.performFinish(AbstractWizard.java:356)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:853)
> at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:438)
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:619)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1182)
> at org.jboss.reddeer.swt.handler.WidgetHandler$4.run(WidgetHandler.java:333)
> at org.jboss.reddeer.swt.util.Display$VoidResultRunnable.run(Display.java:184)
> at org.jboss.reddeer.swt.util.Display$VoidResultRunnable.run(Display.java:1)
> at org.jboss.reddeer.swt.util.Display$ErrorHandlingRunnable.run(Display.java:150)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3774)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3412)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
> at org.eclipse.jface.window.Window.open(Window.java:808)
> at org.eclipse.ui.internal.handlers.WizardHandler$Import.executeHandler(WizardHandler.java:158)
> at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:290)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
> at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
> at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:159)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
> at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1182)
> at org.jboss.reddeer.swt.handler.MenuHandler$5.run(MenuHandler.java:116)
> at org.jboss.reddeer.swt.util.Display$VoidResultRunnable.run(Display.java:184)
> at org.jboss.reddeer.swt.util.Display$VoidResultRunnable.run(Display.java:1)
> at org.jboss.reddeer.swt.util.Display$ErrorHandlingRunnable.run(Display.java:150)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3774)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3412)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.jboss.reddeer.eclipse.core.UITestApplication.start(UITestApplication.java:47)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3632) Performance issue retrieving data source and translator definitions through the AdminFactory
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-3632?page=com.atlassian.jira.plugin... ]
Barry LaFond commented on TEIID-3632:
-------------------------------------
Connected to a remote server containing 30+ data sources
Designer refresh() method compiles and caches Translator, Data Source and VDB objects using the following API calls
Loading translator definitions (names and properties)
* admin.getTranslators()
* admin.getTranslatorPropertyDefinitions()
>> 120 CLI calls (3 per translator to get all 3 property definition types: Override, Import & Extension props)
Load data source template names
* admin.getDataSourceTemplateNames()
> 24 CLI calls (24 different resource adapters & data source types)
Load data source template names
* admin.getDataSourceNames()
> 24 CLI calls (24 different resource adapters & data source types)
Retrieve DS properties for 35 data sources
* over 1800 CLI calls to get properties for 35 data sources
* Looks like all the ds types are checked for each data source
AdminFactory re-uses the following methods to obtain maps or arrays or maps of "names". Seems inefficient to make the same CLI calls multiple times within the same call stack.
* getInstalledResourceAdaptorNames()
* getResourceAdapterNames()
* getDeployedResourceAdaptorNames()
* getDataSourceTemplateNames()
* getConnectionFactoryNames()
> Performance issue retrieving data source and translator definitions through the AdminFactory
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3632
> URL: https://issues.jboss.org/browse/TEIID-3632
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
>
> Based on the issue described in TEIIDDES-2592, we discovered that connecting to a remote server that contained ~ 40 data sources required > 10 minutes to refresh the Server view in Teiid Designer. After some debugging it appeared that some of the current behavior in AdminFactory results multiple redundant CLI calls to retrieve intermediate information to compile even a simple list of data source names.
> In Teiid Designer, we modified our forked Admin8Factory to define a few cached sets of data that get cleared if data is changed by our ExecutionAdmin class for any created or deleted data sources.
> Note that Designer's Server management paradigm includes the requirement to view the DS/Translator/VDB contents on the server.
> So I'm assuming that there could be some benefit if Teiid AdminFactory adapted a similar approach to improving the performance/behavior of the internal methods of this class.
> see: https://github.com/Teiid-Designer/teiid-designer/blob/master/plugins/teii... for details
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3632) Performance issue retrieving data source and translator definitions through the AdminFactory
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3632?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-3632:
-------------------------------------
Assignee: Ramesh Reddy (was: Steven Hawkins)
> Performance issue retrieving data source and translator definitions through the AdminFactory
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3632
> URL: https://issues.jboss.org/browse/TEIID-3632
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
>
> Based on the issue described in TEIIDDES-2592, we discovered that connecting to a remote server that contained ~ 40 data sources required > 10 minutes to refresh the Server view in Teiid Designer. After some debugging it appeared that some of the current behavior in AdminFactory results multiple redundant CLI calls to retrieve intermediate information to compile even a simple list of data source names.
> In Teiid Designer, we modified our forked Admin8Factory to define a few cached sets of data that get cleared if data is changed by our ExecutionAdmin class for any created or deleted data sources.
> Note that Designer's Server management paradigm includes the requirement to view the DS/Translator/VDB contents on the server.
> So I'm assuming that there could be some benefit if Teiid AdminFactory adapted a similar approach to improving the performance/behavior of the internal methods of this class.
> see: https://github.com/Teiid-Designer/teiid-designer/blob/master/plugins/teii... for details
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months