Uploaded image for project: 'Sqoop (Retired)'
  1. Sqoop (Retired)
  2. SQOOP-1680

DOC: Create an Public API doc for the Sqoop repository.

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 1.99.5
    • None
    • None

    Description

      Having a good doc for repository will encourage us to create better code going forward to support other types of repository.

      Even the repo upgrade can be its own clean api

      Well we have connector developer guide that details the responsibilities.

      I have similar thoughts for the exec engine and repository.

      You many ask why? If we think ourselves as external developers we will take less shortcuts and make our code mode extensible and clean is my thought.

      for instance

      Should the create link api enforce the unique constraint on name or the database table should. these are not documented anywhere clearly for someone trying to add a new repo and the recommended practices are nice to have

      Attachments

        Issue Links

          Activity

            Sqoop Repository API doc created for public facing APIs

            https://cwiki.apache.org/confluence/display/SQOOP/Sqoop+Repository+API

            vybs Veena Basavaraj added a comment - Sqoop Repository API doc created for public facing APIs https://cwiki.apache.org/confluence/display/SQOOP/Sqoop+Repository+API

            abec let me know if you are planning to add docs for repo API as part of any post gres work? Else I will document it in the wiki

            vybs Veena Basavaraj added a comment - abec let me know if you are planning to add docs for repo API as part of any post gres work? Else I will document it in the wiki
            gwenshap Gwen Shapira added a comment -

            +1

            I agree we can improve the docs for our APIs. I think improving the existing java docs is the way to go about it.

            gwenshap Gwen Shapira added a comment - +1 I agree we can improve the docs for our APIs. I think improving the existing java docs is the way to go about it.

            I have no preference where we document or what format it is, but it should exist in one place with good details.

            I can clearly highlight where we have not put in effort to document our assumptions and best practices for the apis we have added.

            vybs Veena Basavaraj added a comment - I have no preference where we document or what format it is, but it should exist in one place with good details. I can clearly highlight where we have not put in effort to document our assumptions and best practices for the apis we have added.
            gwenshap Gwen Shapira added a comment -

            I'd rather not duplicate docs, and the repository also have JavaDocs.
            I thought JavaDocs are the standard method for documenting internal APIs.

            Using my usual example:
            Kafka has an excellent ConfigDef library used internally. The JavaDocs are great and ensured new devs use this correctly, but there's no other documentation, since this is internal. Producer and Consumer are external and have real documentation which we maintain, with specific examples on how to use them, best practices, etc.

            gwenshap Gwen Shapira added a comment - I'd rather not duplicate docs, and the repository also have JavaDocs. I thought JavaDocs are the standard method for documenting internal APIs. Using my usual example: Kafka has an excellent ConfigDef library used internally. The JavaDocs are great and ensured new devs use this correctly, but there's no other documentation, since this is internal. Producer and Consumer are external and have real documentation which we maintain, with specific examples on how to use them, best practices, etc.

            People

              vybs Veena Basavaraj
              vybs Veena Basavaraj
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: