January 2013 - teiid-designer-issues

[JBoss JIRA] (TEIIDDES-1129) Create IContentOutlinePage Implementation For Model Extension Definition Editor

by Dan Florian (JIRA)

[ https://issues.jboss.org/browse/TEIIDDES-1129?page=com.atlassian.jira.plu... ] Dan Florian updated TEIIDDES-1129: ---------------------------------- Fix Version/s: Future (was: 8.1) > Create IContentOutlinePage Implementation For Model Extension Definition Editor > ------------------------------------------------------------------------------- > > Key: TEIIDDES-1129 > URL: https://issues.jboss.org/browse/TEIIDDES-1129 > Project: Teiid Designer > Issue Type: Task > Components: Editors, Views > Affects Versions: 7.6 > Reporter: Dan Florian > Assignee: Dan Florian > Fix For: Future > > > The outline page view should correspond to the model extension definition (MED) structure and be patterned after Eclipse's Java editor. Selection should be sync'd between the MED editor and the outline view. Actions in the outline should correspond to the appropriate actions in the editor. For instance, if selecting a metaclass in the outline view, two actions could be "Add Extension Property" and "Remove Metaclass." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIIDDES-1144) Investigate If The Model Extension Definition Validation Done In The Editor Can Be Done Using XSD Validation

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIIDDES-1144?page=com.atlassian.jira.plu... ] Barry LaFond updated TEIIDDES-1144: ----------------------------------- Fix Version/s: Future (was: 8.1) > Investigate If The Model Extension Definition Validation Done In The Editor Can Be Done Using XSD Validation > ------------------------------------------------------------------------------------------------------------ > > Key: TEIIDDES-1144 > URL: https://issues.jboss.org/browse/TEIIDDES-1144 > Project: Teiid Designer > Issue Type: Task > Components: Editors > Affects Versions: 7.6 > Reporter: Dan Florian > Assignee: Dan Florian > Fix For: Future > > > The validation being done as the user is editing a MED is done using the ModelExtensionDefinitionValidator (MEDValidator). This validator tries to recreate in code what the MED XSD does when the MED file is parsed. The MEDValidator should use XSD validation libraries to perform validation to guarantee that MED problem markers agree with those reported in the editor. > Looking into this a bit I found that XSD validation libraries only validate entire documents. So to validate just an element value or simple type value does not seem possible. One possible way around this might be to create XML fragments to match the smaller sections of that document that require validation. Research still needs to be done on the feasibility of this idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIIDDES-1150) Model Extension Definition Problem Markers For Models Should Support Quick Fix

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIIDDES-1150?page=com.atlassian.jira.plu... ] Barry LaFond reassigned TEIIDDES-1150: -------------------------------------- Assignee: Mark Drilling (was: Dan Florian) > Model Extension Definition Problem Markers For Models Should Support Quick Fix > ------------------------------------------------------------------------------ > > Key: TEIIDDES-1150 > URL: https://issues.jboss.org/browse/TEIIDDES-1150 > Project: Teiid Designer > Issue Type: Enhancement > Components: Editors > Affects Versions: 7.6 > Reporter: Dan Florian > Assignee: Mark Drilling > Fix For: 8.1 > > > Model problem markers related to MEDs should have a quick fix option. Currently there are 2 MED problem markers: > (1) MED found in model is not registry. Quick fix should offer to save that MED to a file in the workspace. > (2) MED found in model is different than the same MED in the registry. Quick fix should offer to update the model to the registry copy of the MED. > I'm thinking that the quick fix in each case would not offer to fix all markers of the same error at the same time. However, the quick fix for (1) could offer to save all MEDs in a common directory. And the quick fix for (2) could offer to update all models to the MED version. These options might be nice and deserve more thought. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIIDDES-1151) Model Extension Definition Version History Should Be Persisted Along With The Registry

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIIDDES-1151?page=com.atlassian.jira.plu... ] Barry LaFond updated TEIIDDES-1151: ----------------------------------- Fix Version/s: Future (was: 8.1) > Model Extension Definition Version History Should Be Persisted Along With The Registry > -------------------------------------------------------------------------------------- > > Key: TEIIDDES-1151 > URL: https://issues.jboss.org/browse/TEIIDDES-1151 > Project: Teiid Designer > Issue Type: Task > Components: Modeling > Affects Versions: 7.6 > Reporter: Dan Florian > Assignee: Dan Florian > Fix For: Future > > > Persisting a version history of MED stored in the registry will help determine if the MED the user wants to register is newer or older than the one in already in the registry. The MED business object does have a version number but there are problems with using that to determine if one MED is newer/older than another MED. For instance, in a multi-user environment the same MED could be updated by different users. Each user could end up with a MED with the same version but with different content. And those MEDs could end up in the hands of other users who could also create new versions. Of course an enterprise could be diligent about controlling MED versioning using their own version-control system and possibly get around this issue. With that said, persisting a MED version history by using something like a checksum/sha-1 would remove the problems associated with relying on the version number at least for a workspace. We might also look at writing an exporter/importer to export the version history and then import into another workspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIIDDES-1552) More optimistic dependent join planning should be implemented when TEMP tables are used for data inputs in WHERE IN clause

by Tanmoy Palit (JIRA)

Tanmoy Palit created TEIIDDES-1552: -------------------------------------- Summary: More optimistic dependent join planning should be implemented when TEMP tables are used for data inputs in WHERE IN clause Key: TEIIDDES-1552 URL: https://issues.jboss.org/browse/TEIIDDES-1552 Project: Teiid Designer Issue Type: Enhancement Components: Modeling Affects Versions: 7.7 Environment: Windows Server 2008 Reporter: Tanmoy Palit Priority: Minor Fix For: Future Please follow: https://community.jboss.org/thread/217306 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIIDDES-1037) Data types inported from flat file partially implemented in wizard

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIIDDES-1037?page=com.atlassian.jira.plu... ] Barry LaFond updated TEIIDDES-1037: ----------------------------------- Fix Version/s: Future (was: 8.1) Workaround Description: On import, users can view the file contents and visually see column datatypes and set manually on each column. Pushing to Future > Data types inported from flat file partially implemented in wizard > ------------------------------------------------------------------ > > Key: TEIIDDES-1037 > URL: https://issues.jboss.org/browse/TEIIDDES-1037 > Project: Teiid Designer > Issue Type: Bug > Components: Import/Export > Affects Versions: 7.5 > Reporter: Paul Nittel > Assignee: Barry LaFond > Fix For: Future > > Attachments: FlatFileDataTypes_NOT.png > > > The new Flat File metadata importer is great! Not having to write the TEXTTABLE function is a fine example of usability improvement. > I noticed, during import, a dialog option that indicated datatypes can be the second line in the data file (column names being the first). That, and its associated help, are the only reference to this possibility (see attached screenshot). Without the actual functionality, it's confusing. > Later in the wizardly process, the column names row number is captured. I suspect the types row--if present, and its use desired by the user--should also be determined at that point. > The ability of importing the datatypes from the flat file would, IMHO, really enhance what is already a superb importer! (Yeah, I _do_ like it!) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-designer-issues January 2013