November 2008 - dna-issues - Jboss List Archives

[JBoss JIRA] Commented: (DNA-55) REST-based API for remote access and usage

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-55?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-55: ------------------------------------ Another interesting article about integration of enunciate (http://enunciate.codehaus.org/) and JBoss Seam - "A Rich Web Service API for Your Favorite Framework, Part 2: JBoss Seam": http://java.dzone.com/articles/a-rich-web-service-api-your-fa-0 > REST-based API for remote access and usage > ------------------------------------------ > > Key: DNA-55 > URL: https://jira.jboss.org/jira/browse/DNA-55 > Project: DNA > Issue Type: Feature Request > Components: Server, Web Application > Reporter: Randall Hauch > Fix For: 0.4 > > > Create a DNA server that uses a REST-based API, allowing client applications to access and use the repository using HTTP for protocol/transport. > AtomPub is also very interesting (as it is RESTful) for a message structure, but it doesn't currently support hierarchical data. And although one could build a repository to be flatter (or at least exposed though collections; see how Bento does it: http://www.filemaker.com/bento/), it may be difficult to have no way of interacting with the hierarchical data. Bento and iTunes both show how powerful user-defined collections (and "smart collections") can be, so maybe adopting a collection-only approach would work (at least for remote access). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Sergiy Litsenko commented on DNA-37: ------------------------------------ >From Sergiy: > The difficult part of database metadata mapping is that different vendors using different concept of database instances - Microsoft/Sybase uses multiple databases as part of single server instance, Oracle uses single database but multiple schemas. We may review how database access tools like Aqua Data Studio (based on Java Swing and JDBC) intepreting such graphs. I'm talking about the root part of such graph - from root node to let's say table node. > For example: > <root database node>/<sub graph that difficult to map in generic way>/tables/... > <root database node>/<sub graph that difficult to map in generic way>/views/... > <root database node>/<sub graph that difficult to map in generic way>/users/... > > We need to think more how we will map subgraph highlighted above onto different db vendors concepts: > MS SQL/Sybase, etc: > <root database node>/databases/<db name>/user tables/<user name>.<table name> > <root database node>/databases/<db name>/system tables/sys.<table name> > <root database node>/databases/<db name>/views/<view name> > > > Oracle and others similar: > <root database node>/schema/<user name>/tables/<table name> > <root database node>/schema/<user name>/views/<view name> > > We may consider merging both styles together or having them separate (both approaches have advantages and disadvantages). I would prefer > generic, merged concept view - for benefits of DNA-JCR and REST toghether so clients don't have to change graph based on particular vendor. >From Randall: Do we really think it's our job to come up with a single model? Why can't we simply expose what the database exposes? Like you said, it's mostly at the high-level (what I'd call the organizational level, above the tables/views/procedures/etc.). How about taking it one step at a time, and focusing on getting the functionality there to expose the same organizational structure that the database uses. At some point, we'll probably want to come up with a single approach, but even then I think we'd want to make it optional (specified in the metadata connector). I also think that we should use mixins for the type information (or maybe even node types that are extensible to allow any properties), and that means we could actually not have any nodes that exist to collect the types. This is much more along the lines of a So, Oracle's schema might show up as content: <db:schema jcr:name="Products"> <db:table jcr:name="PRODUCTS"> <db:column jcr:name="ID" ... /> <db:column jcr:name="NAME" ... /> ... <db:primaryKey ... /> ... </db:table> <db:table jcr:name="TABLES" jcr:mixins="db:system" ...> ... </db:table> <db:view ...> ... </db:view> <db:procedure> ... </db:procedure> </db:schema> I've shown that any system table/view/procedure could have an additional "System" mixin. The great thing about this approach (of using mixins rather than names in a hierarchy) is that you can more readily build queries to get the content in any structure you want. I've used an XML notation; for details about this notation, see the note somewhere after paragraph 5 in http://www.jboss.org/file-access/default/members/dna/freezone/docs/0.3/ma.... >From Sergiy: > Anyway, for both styles we may add generic metadata subnode about RDBMS capabilities (that will hold all not specific to database object propertise like supportsMixedCaseIdentifiers(), storesUpperCaseIdentifiers(), supportsAlterTableWithAddColumn(), etc): > > <root database node>/capabilities >From Randall: Yup. <db:capabilities supportsMixedCaseIdentifiers="true" db:supportsUpperCaseIdentifiers="true" ... /> >From Sergiy: Sub nodes of table, view, etc nodes are pretty easy to model because they are similir for many databases. I was thinking about something similar to following (I guess we may have design sessions and may refactor it later): .../tables/<table name>/data [default primary type, so it can be omitted] table's data records .../tables/<table name>/data/record 1 .../tables/<table name>/data/record N >From Randall: Let's table the data discussion for the moment. I've got very different ideas about how that will work, since this is too flat for tables with millions of rows. We may want to do something like this for a sampling of the data (something that's very useful when you're dealing with metadata, but even then there are enterprise security issues with this). >From Sergiy: .../tables/<table name>/columns/<column name> .../tables/<table name>/constraints/<constraint name> .../tables/<table name>/indexes/<index name> >From Randall: As I mentioned above, this is more straightforward. > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Work started: (DNA-37) Federate schema information from relational sources

by Sergiy Litsenko (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Work on DNA-37 started by Sergiy Litsenko. > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-254) CreateNodeRequest does not allow passing in location of existing parent

by Randall Hauch (JIRA)

CreateNodeRequest does not allow passing in location of existing parent ----------------------------------------------------------------------- Key: DNA-254 URL: https://jira.jboss.org/jira/browse/DNA-254 Project: DNA Issue Type: Bug Components: API, Connectors, Graph Affects Versions: 0.3 Reporter: Randall Hauch Assignee: Randall Hauch Priority: Critical Fix For: 0.4 The graph Request framework was designed to use Location objects to refer to nodes, but the CreateNodeRequest only allows a Location object for the new node (and not the parent). A little background may be important. When working with nodes, it's often beneficial for connectors to have any source-specific information about the node included in the request. The Location class was designed to serve this purpose, and as such each Location may contain the Path of the node and/or identification properties (e.g., UUID, or a source-specific key). Since, the Request classes use Locations for their references to nodes, the Requests pass along any path or identification information along with the request. In general, clients start off only knowing the path (sometimes they instead know the UUID), and so the connector framework specifies that the Location objects that are inputs on the requests need not be complete, and that the connector is to include in the request's response the _actual_ and complete location of any node. It's then recommended that when the client receives the response, they use the _actual_ location. The procedure for creating nodes always involves specifying where the new node is to be placed. In the CreateNodeRequest, this took the form of a Location specifying the path (and optionally additional identification properties). The parent was then inferred from the path, but the request doesn't contain a Location for the parent. In other words, the request carries no identification information for the parent, requiring that the connector locate the parent by path (which may more expensive than locating by the source-specific identification properties). The CreateNodeRequest needs to be changed so that it includes a Location for the existing parent. The request could then represent the child with a mandatory name. (Note that this also would get around the previous constraint that the Location for the new child must have a path; with this new approach, the Location of the parent will include a path and/or the identification properties.) It remains a question whether the CreateNodeRequest should be corrected (changed, thereby breaking backward compatibility of any connectors developed against 0.3), or be done through a new Request class. It should be noted that the current approach really doesn't work well, and that since we're still pre-1.0, we can maybe afford to correct the connector API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

3
3
0 / 0

[JBoss JIRA] Assigned: (DNA-37) Federate schema information from relational sources

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Randall Hauch reassigned DNA-37: -------------------------------- Assignee: Sergiy Litsenko > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Sergiy Litsenko > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (DNA-37) Federate schema information from relational sources

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Randall Hauch updated DNA-37: ----------------------------- Fix Version/s: 0.4 (was: Future Releases) Moving to 0.4. > Federate schema information from relational sources > --------------------------------------------------- > > Key: DNA-37 > URL: https://jira.jboss.org/jira/browse/DNA-37 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes the database schema information for a relational database (via JDBC) into the federated repository. This would make it possible to have a repository provide information about the databases in an organization. One choice would be whether to import (and copy) the schema structure, or to provide access to it in real time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Work started: (DNA-40) Persistant storage for information not stored in other repository sources

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.... ] Work on DNA-40 started by Randall Hauch. > Persistant storage for information not stored in other repository sources > ------------------------------------------------------------------------- > > Key: DNA-40 > URL: https://jira.jboss.org/jira/browse/DNA-40 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Reporter: Randall Hauch > Assignee: Randall Hauch > Fix For: 0.4 > > > Create a federation connector that is able to manage information in a relational database using a DNA-defined schema. This would enable the persistant storage of information that isn't being managed by other connectors. > Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (DNA-36) Federate content from SVN

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-36?page=com.atlassian.jira.plugin.... ] Randall Hauch updated DNA-36: ----------------------------- Summary: Federate content from SVN (was: Federate content from SVN and other SCM systems) Changed the title to reflect the primary goal. Connectors for other SCM systems will be managed through other issues. > Federate content from SVN > ------------------------- > > Key: DNA-36 > URL: https://jira.jboss.org/jira/browse/DNA-36 > Project: DNA > Issue Type: Feature Request > Components: Connectors > Affects Versions: 0.4 > Reporter: Randall Hauch > Assignee: Serge Emmanuel Pagop > Priority: Minor > Fix For: 0.4 > > > Create a connector for the federation engine that contributes and exposes content stored in a source control management (SCM) system into the federated repository. This would enable integration of files managed by SVN (or CVS, etc.) to be accessible via JCR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (DNA-11) Sequencer configuration should be stored in the repository

by Randall Hauch (JIRA)

[ https://jira.jboss.org/jira/browse/DNA-11?page=com.atlassian.jira.plugin.... ] Randall Hauch updated DNA-11: ----------------------------- Fix Version/s: 0.5 (was: 0.4) Moving these issues to 0.5, since we won't be addressing configuration quite yet. The current approach for configuring the sequencers still works very well. 0.4 is focusing on completing the JCR implementation (at least a large portion of it), and that takes priority right now. > Sequencer configuration should be stored in the repository > ---------------------------------------------------------- > > Key: DNA-11 > URL: https://jira.jboss.org/jira/browse/DNA-11 > Project: DNA > Issue Type: Feature Request > Components: Sequencers > Reporter: Randall Hauch > Fix For: 0.5 > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > The configuration information for each sequencer should be stored in the repository. This configuration information should include the rules dictating when the sequencer applies, the name of the ISequencer implementation class, and the Maven classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-174) Should ensure single versions required for 3rd-party dependencies within same classloader

by Johnny Verhaeg (JIRA)

Should ensure single versions required for 3rd-party dependencies within same classloader ----------------------------------------------------------------------------------------- Key: DNA-174 URL: http://jira.jboss.com/jira/browse/DNA-174 Project: DNA Issue Type: Task Components: Development Environment Affects Versions: 0.1 Reporter: Johnny Verhaeg Priority: Minor Fix For: 0.2 We should write a script that will be executed after the build and produce some reports indicating: - The list of 3rd-party dependencies, both direct & indirect - Any potential conflicts in dependency versions between projects or other dependencies - A tree of non-test-related dependencies by project Developers would then need only to add classloader knowledge into the mix when handling dependency version conflict resolution. It would be nice if the resulting reports could be accessed in the same manner as build & test results via Hudson. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

3
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues November 2008