Opened 9 years ago

Closed 9 years ago

#1066 closed task (complete)

support wildcard matching in DatabaseZoneHandle::find().

Reported by: jinmei Owned by: vorner
Priority: medium Milestone: Sprint-20110830
Component: data source Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 5.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

See commit 90b94ac6bc56985107d79ada95bfaa3753d6f76c of trac817a for
prototype implementation. But this is quite incomplete. We should
consider various corner cases as we did for the in memory data source.

(but the actual implementation doesn't have to stick to the way that
the prototype does)

This task depends on #1060, #1061, #1062 (but can be done in parallel
with other find() support tasks).

Subtickets

Change History (10)

comment:1 Changed 9 years ago by stephen

  • Estimated Difficulty changed from 0.0 to 5

comment:2 Changed 9 years ago by stephen

  • Milestone changed from Next-Sprint-Proposed to Sprint-20110816

comment:3 Changed 9 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:4 Changed 9 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to assigned

Hello

It should be ready for review. I tried to take whatever tests I found for the in-memory data source, with the exception of ANY queries (currently, the DB doesn't support them).

The branch is based on merge of current master and #1065, as it uses code from both #1063 (merged) and #1065.

I found a strange thing in the in-memory tests. When we have a wildcard under delegation and query with GLUE_OK, it returns DELEGATION. But provided only the wildcard match is disabled because of the NS, shouldn't it be NXDOMAIN (since it can't be constructed, but we still get below the delegation). Currently this branch copies the in-memory behaviour, but should we change it?

comment:5 Changed 9 years ago by vorner

  • Status changed from assigned to reviewing

comment:6 Changed 9 years ago by jelte

  • Owner changed from UnAssigned to jelte

comment:7 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

I have taken the liberty to add one test case (direct query for cancel.here.wild.example.org/AAAA) and fixed one typo in a comment

generally; I think the code looks ok (i predict lots of conflicts again, btw, searchForRecords() is gone :p), but the find() method is getting extremely long now (almost 200 lines) while it structurally looks like it can be split up quite well. Lot's of lines are log calls but still :) Though I understand if we want to get the functionality complete and then move some code around (also to try and minimize conflicts), I'll leave it up to you, but we should make a ticket then.

Regarding the GLUE_OK case; it's one part interpretation of 'glue is ok', and one part 'just' a matter of how we want to handle the response (cause in effect it shouldn't matter that much). I see no objections to making 'GLUE_OK' mean 'ignore zone cuts completely' but we should then probably rename it (since below-zone-cut-data is not always glue, but i don't think that's taken into account now either). If there is no use-case for the current behaviour it might indeed be more logical to have an ignore-zone-cut option.

comment:8 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

I solved the conflicts.

Looking at the function, yes, it is little bit long. However, I don't see a clean way to cut it right now, so lets put it into a new ticket. I'll create one when it is merged. OK?

The glue OK mode, well, let's leave it for now. I don't think it matters at all, it just looked odd. This is one of the things that can be postponed to the sixth year, „General cleanup of code“ ;-).

comment:9 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

OK, please go ahead

comment:10 Changed 9 years ago by vorner

  • Resolution set to complete
  • Status changed from reviewing to closed

Thanks, ticket created and branch merged.

Note: See TracTickets for help on using tickets.