### Communities

tag:snake search within a tag
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
created:<1w created < 1 week ago
post_type:xxxx type of post
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Parent

# How to break infinite loop in CTE

+5
−0

I have a parent-child relation in my table, with possibly circular cases. Is it possible to break the infinite recursion in CTE checking values of all previous rows? I would need something like this:

with my_cte(childId, parentId, col1)
AS (
SELECT r.childId, r.parentId, r.col1
FROM My_Table r WHERE r.childId = 'x' AND (r.col1 = 1 or r.col1 = 2)
UNION ALL
SELECT rel.childId, rel.parentId, rel.col1
FROM My_Table rel INNER JOIN my_cte sd ON rel.childId = sd.parentId where (rel.col1 = 1 OR rel.col1 = 2) AND ...
-- check that rel.childId, rel.parentId not in previous rows
)
SELECT DISTINCT * from shared_documents


How can I achieve this? Or how to approach this?

Example table with records would be:

childId parentId col1
1 3 1
1 4 1
3 5 1
5 1 1 -- circular case
6 2 1
5 7 1

If I ask for hierarchy related to 1, I should get

childId parentId col1
1 3 1
1 4 1
3 5 1
5 1 1 -- circular case
5 7 1
• 1 has two parents: 3 and 4.
• 3 has 1 parent: 5
• 5 has 2 parents: 1 and 7. But 1 brings the infinite loop, so the query should ignore this. And continue to the next row.
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

#### 1 comment thread

Post
+2
−0

Estela's answer provides great insight about how to do it also in SQL Server. Unfortunately, there does not seem to be a build-in array functionality, so one way is to rely on strings as shown here.

Basically, instead of accumulating values in an array, a string does this (way less efficiently for many records, I would say).

In this case, a query that seems to provide the results you are looking for is the following (some security check does not allow to post the query, so I am using SQL fiddle for sharing it):

http://sqlfiddle.com/#!18/a50101/1

Note: considering how complex things might get (edge cases might add up to the logic), this type of query might be better be done in a language/framework like C++, Java or .NET, unless there is a very strong reason to remain in SQL. These allow for much more flexibility, considering the iterative nature of the algorithm (not so suitable for set based operations) and also provide way better-debugging capabilities.

Why does this post require moderator attention?
You might want to add some details to your flag.

#### 1 comment thread

Peter Taylor‭ wrote about 3 years ago

Stored procedures might be a sensible compromise. I'm not aware of step-through debuggers, but they allow you to do the iterative part on the SQL server without network overhead each time round the loop.

Alexei‭ wrote about 3 years ago

@PeterTaylor - While I have experience writing stored procedures, I am also aware of the many disadvantages that they might bring in the project. AFAIK, unless there is a really serious reason to incorporate business logic in a stored procedure (e.g. avoid fetching huge amounts of data in the application layer), having the business logic in the application layer is the recommended way nowadays.

artaxerxe‭ wrote about 3 years ago

@Alexei 'this type of query might be better be done in a language/framework like C++, Java or .NET'. Yes, I'm forced to remain to SQL. But do you mean to use an ORM or do you mean to make the logic from such a framework? I ask because second option seems to me not efficient.

Alexei‭ wrote about 3 years ago

@artaxerxe‭ If you don't need to compute this too often and the data volume is pretty low (<100K records, also depends on the frequency), you can fetch all the required data in the application layer and implement the algorithm there. Languages such as Java or C# are better equipped for recursivity, tree traversal algorithms or similar.

artaxerxe‭ wrote about 3 years ago · edited about 3 years ago

@Alexei In my case, I think this wouldn't be recommendable, even if I shouldn't stick with SQL. Anyway, taking 100K rows form DB to parse them on the middleware seems to me not a good idea. I think this should be done on the DB side. Your SQL is quite useful for me except the recursivity limitation. I think because of this I have to move the logic in a stored procedure. Although maximum recursivity number would be quite enough I should consider edge cases.