| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle Conditional CONNECT BY - Possible?
Hi Edzard,
Thanks for your quick reply. It turns out I can't really do what I wanted without running into an infinite loop. So instead I wrote a procedure to bring in the main website's links and any links in a different website that are a direct child to the first website:
/*************************************************************************** ********************************/
PROCEDURE GET_SITE_MAP_H
( websiteID IN NUMBER DEFAULT NULL,
siteMap OUT REFCURSOR)
IS
siteMapTable SITEMAPTABLETYPE := SITEMAPTABLETYPE();
subSiteMapTable SITEMAPTABLETYPE := SITEMAPTABLETYPE();
CURSOR siteMapCursor IS
SELECT
LEVEL as depth,
name,
DECODE(is_parent||'!'||link_website_id||link_element_id||link_url,'N!', NULL,
DECODE(target,
'_top',
'<a
'_blank',
'<a
'<a href="/default.asp?elementID='||id||'"
'||'target="_top">')) AS URL,
link_website_id,
link_element_id
FROM cfit_element
WHERE on_toc = 'Y'
START WITH parent_id IS NULL AND website_id = websiteID
CONNECT BY PRIOR id = parent_id
ORDER BY GET_GLOBAL_ORDER_NUMBER(id, website_id,
GET_HIGHEST_ORDER_NUMBER_LEN(website_id)) ASC;
BEGIN
FOR siteMapRecord IN siteMapCursor LOOP
siteMapTable.EXTEND;
siteMapTable(siteMapTable.COUNT) :=
SITEMAPRECORDTYPE(
siteMapRecord.depth,
siteMapRecord.name,
siteMapRecord.URL);
IF siteMapRecord.link_website_id IS NOT NULL OR
siteMapRecord.link_element_id IS NOT NULL THEN
subSiteMapTable :=
GET_SITE_MAP_H_SUB(siteMapRecord.link_website_id,
siteMapRecord.link_element_id, siteMapRecord.depth);
FOR i IN 1..subSiteMapTable.COUNT LOOP
siteMapTable.EXTEND;
siteMapTable(siteMapTable.COUNT) := subSiteMapTable(i);
END LOOP;
END IF;
END LOOP;
OPEN siteMap FOR
SELECT depth, name, url
FROM TABLE(CAST(siteMapTable AS SITEMAPTABLETYPE));
END;
/*************************************************************************** ********************************/
FUNCTION GET_SITE_MAP_H_SUB
( websiteID IN NUMBER DEFAULT NULL,
parentID IN NUMBER DEFAULT NULL,
currentDepth IN NUMBER DEFAULT NULL)
RETURN SITEMAPTABLETYPE IS
subSiteMapTable SITEMAPTABLETYPE := SITEMAPTABLETYPE();
CURSOR subSiteMapCursor IS
SELECT
currentDepth + LEVEL as depth,
name,
DECODE(target,
'_top',
'<a
'_blank',
'<a
'<a href="'||GET_ELEMENT_URL(website_id, NULL,
NULL)||'default.asp?elementID='||id||'" '||'target="_top">') AS URL,
link_website_id,
link_element_id
FROM cfit_element
WHERE on_toc = 'Y'
START WITH NVL(parent_id,-1) = NVL(parentID,-1) AND website_id =
websiteID
CONNECT BY PRIOR id = parent_id
ORDER BY GET_GLOBAL_ORDER_NUMBER(id, website_id,
GET_HIGHEST_ORDER_NUMBER_LEN(website_id)) ASC;
BEGIN
FOR subSiteMapRecord IN subSiteMapCursor LOOP
subSiteMapTable.EXTEND;
subSiteMapTable(subSiteMapTable.COUNT) :=
SITEMAPRECORDTYPE(
subSiteMapRecord.depth,
subSiteMapRecord.name,
subSiteMapRecord.URL);
END LOOP;
RETURN subSiteMapTable;
/*************************************************************************** ********************************/
Thanks for your help!
Leo
"Edzard" <edzard_at_volcanomail.com> wrote in message news:5d75e934.0203170429.727f5b0e_at_posting.google.com...
> Hi, > > Although I'm not familiar with the subject "website building > application", I like to react to your message. The procedural code > that you listed is clear to read, also without the particular subject > knowledge. It is a nice demo of the use of records and tables within > PL/SQL, if I may judge. > > But I wonder why the CONNECT BY was not suited. I assume that a > solution within SQL is peferred over the use of procedural code. From > your code, the following SQL can be derived: > > CONNECT BY PRIOR.link_website_id IS NOT NULL > AND website_id = PRIOR.link_website_id > AND NVL (parent_id, -1) = NVL (PRIOR.link_element_id, -1)) > OR PRIOR.link_website_id IS NULL > AND PRIOR.is_parent = 'Y' > AND website_id = PRIOR.website_id > AND NVL (parent_id, -1) = NVL (PRIOR.parent_id, -1) > > As I say, I'm not familiar with what is really meant here, but I hope > that this SQL correctly expresses the application logic. I also > assume that you started with a similar expression, maybe using an > equivalent DECODE or CASE construction. Why did that not succeed? Is > there some restriction on the clauses in a CONNECT BY clause? I'm > only aware of a restriction on the FROM part, you can not use > CONNECT BY on a join. But that can easily be worked around by > including the join in a view. May be the use of a view is a solution > here too. > > Like to hear, > > EdzardReceived on Tue Mar 19 2002 - 08:42:43 CST
![]() |
![]() |