What should they be: view or virual models?
by Paul Nittel
Some time, way back in the MetaMatrix days, we changed our nomenclature to refer to "view" instead of "virtual" models. I see the word "virtual" creeping back a bit. Personally, I prefer "virtual" since "view" can be verb-ish. Yes, they are kinda like views in the database world.
Anyway, Jopr lists these models as "virtual". Is that politically correct?
Sent from my Fedora laptop :-P
-------
Paul Nittel
JBoss Sr. Quality Assurance Engineer
Red Hat, Inc.
314-336-2907 (81-62907)
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
15 years, 12 months
Re: [teiid-dev] What should they be: view or virual models?
by Ted Jones
"Virtual" in Jopr represents the Enumerated value for model type coming back from Teiid. If "View" is the required terminology then the Enumerated value needs to be changed.
----- Original Message -----
From: "Steven Hawkins" <shawkins(a)redhat.com>
To: "Paul Nittel" <pnittel(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Wednesday, June 30, 2010 11:44:30 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] What should they be: view or virual models?
view was the supposedly correct term, but doesn't map exactly to the db world, since view implies table and our "view layer" is a whole schema including procedures. I would personally like to see the word "view" applied only the way databases do.
----- Original Message -----
From: "Paul Nittel" <pnittel(a)redhat.com>
To: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Cc: "teiid-users" <teiid-users(a)lists.jboss.org>
Sent: Tuesday, June 29, 2010 1:56:24 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] What should they be: view or virual models?
Some time, way back in the MetaMatrix days, we changed our nomenclature to refer to "view" instead of "virtual" models. I see the word "virtual" creeping back a bit. Personally, I prefer "virtual" since "view" can be verb-ish. Yes, they are kinda like views in the database world.
Anyway, Jopr lists these models as "virtual". Is that politically correct?
Sent from my Fedora laptop :-P
-------
Paul Nittel
JBoss Sr. Quality Assurance Engineer
Red Hat, Inc.
314-336-2907 (81-62907)
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 12 months
7.0 release status
by Steven Hawkins
Hello all,
Unless there are any objections, I would like to proceed with the 7.0 release today. In any case there should be no check-ins on the 7.0 branch unless absolutely necessary. Also please have a look at any resolved, but not yet closed issues to see if they should be closed. There will be a lot of teiid.org updates to follow.
Steve
15 years, 12 months
7.0 release status
by Steven Hawkins
Hello all,
We have made excellent progress of 7.0. Ramesh has done a great job collecting together new documentation and ensuring that the Salesforce logic functions correctly. The Designer Team has picked up our build as of Thursday and so far so good. We should make a determination today as to whether we want to release 7.0 tomorrow or cut an RC3 and wait.
7.1 development is also underway. Be sure to work enhancements early as it is rather short cycle.
Steve
15 years, 12 months
Re: [teiid-dev] PostgreSQL Sequences
by Steven Hawkins
Hi Jimmy,
What type of sequence support are you looking for? Full language support?
For Oracle, in designer a sequence may be modeled as a table with a name in source of dual and columns with the name in source set to <sequence name>.[nextval|currentval]. You can use a sequence as the default value for insert columns by setting the column to autoincrement and the name in source to <element name>:SEQUENCE=<sequence name>.<sequence value>. The latter is more of a workaround though, rather than a good solution.
It seems like we would need to extend that support for PostgreSQL and other databases supporting sequences. We should also think about getting sequence information as part of dynamic vdb metadata so this isn't a manual exercise.
For documentation we're always looking for more wiki content, examples, etc. The newer documents, like the admin guide, may be a little lite. So if you see anything omitted, let us know.
Steve
----- Original Message -----
From: "James C Schappet" <james-schappet(a)uiowa.edu>
To: teiid-dev(a)lists.jboss.org
Sent: Monday, June 21, 2010 8:54:47 AM GMT -06:00 US/Canada Central
Subject: [teiid-dev] PostgreSQL Sequences
Quick question: Will teiid ever support sequences in postgres or oracle?
BTW, Theres lots of good work going on here -- CR2 looks good.
Is there some documentation I could help writing?
--Jimmy
--
James Schappet
james-schappet(a)uiowa.edu
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years
PostgreSQL Sequences
by Schappet, James C
Quick question: Will teiid ever support sequences in postgres or oracle?
BTW, Theres lots of good work going on here -- CR2 looks good.
Is there some documentation I could help writing?
--Jimmy
--
James Schappet
james-schappet(a)uiowa.edu
16 years
7.0 CR2
by Steven Hawkins
Hello all,
Today we will post CR2. It contains several fixes and substantial cleanup of the docs. We'll also branch later today so that trunk will become 7.1.
Steve
16 years
Re: [teiid-dev] what should a translator-ws look like?
by John Doyle
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> It would be good to have a map, but we have no such construct in
> calling a stored procedure. The best you can do is have default
> values for parameters and used the named parameter calling syntax. In
> a system function we could have whatever syntax we want, but then we
> have the problem of how to encapsulate the connection information
> (base url, username/password, ws-security, etc.).
>
> The request document is always put together by the user (which may be
> assisted by tooling). Only in the case of http are we trying to force
> fit the query string to be a document. For SOAP you would just
> provide the message body. The proposed document for http is probably
> too restrictive since the parameters names would need to be valid
> element names.
I wonder it it wouldn't be better to require the user to envelope the SOAP message? This would enable us to provide the WS-* headers as other system or UDF functions that could put the appropriate values in the document.
>
> The other considerations are really along the lines of offering
> better/explicit syntax that would be especially suited for rest -
>
> clob http('url', 'path' [, querystring(expr [as name], ...)]
> [header(expr [as name], ...)] [GET|(POST [expr])|...])
>
> but you still like to have username/password, url, and even details of
> https handling (which is not even currently handled in the ws resource
> adapter) encapsulated outside of the vdb so that it could change per
> environment.
>
> As a side note, I'm not sure what the previous use-case was, but
> allowing the user to pass in the endpoint address seems like a leaky
> abstraction.
>
This was done to allow access to REST like sites that served up the same XML at different URLs ( ../Employees/1.xml && ../Employees/2.xml)
> ----- Original Message -----
> From: "Ramesh Reddy" <rareddy(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Tuesday, June 8, 2010 7:57:57 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] what should a translator-ws look like?
>
> This is similar approach you have taken with the File translator, so
> looks good.
>
> I would rather like to see generic map kind of parameter with known
> keys
> for the "endpoint" and "soapaction", that we way if there are any
> other
> headers we need to add then it will stay the same.
>
> In this new calling semantics, who is putting together the request
> (for
> soap) document? The engine? or the user's transformation? I am little
> confused about flow of things from before. If requests always came in
> the form <params><param_name>.. and translator converted them to soap
> or
> http requests, then it makes sense to me.
>
> I do not think I follow your comments in other considerations. Can
> you
> give some examples.
>
> Thanks
>
> Ramesh..
>
> On Mon, 2010-06-07 at 16:15 -0400, Steven Hawkins wrote:
> > Hello all,
> >
> > Based upon the features of the translator-xml, we need a comparable
> translator-ws that has a job of simply invoking a service and
> returning a document (which can then be processed with xmltable or any
> other mechanism). I was thinking of exposing the procedure:
> >
> > XML invoke(XML request, String endpoint, String soapaction) - both
> endpoint and soapaction default to null and the result is available as
> the return parameter.
> >
> > With the HTTP mode:
> >
> > -with parameter invocation the request document is expected to be in
> the format
> <params><para_name>value</para_name><param_name1>...</params>. The
> simplest way to form such a doc is with xmlforest - xmlelement(params,
> xmlforest(value as param_name, value1 as param_name1 ...))
> >
> > -Path info will be taken from endpoint if it's specified and will be
> expected to be a relative path.
> >
> > -soapaction would not be used.
> >
> > Basic usage would then be:
> >
> > call ws-model.invoke(request = value)
> >
> > Other considerations:
> >
> > We may also want to add system function(s) with nearly the same
> approach to allow for ad hoc, non-JCA based service calls.
> > We may want to add more explicit calling functionality for http to
> support rest.
> >
> > Steve
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years
