History

sleto-it 0ba532b16a Doc - Replication Refactor - Part 1 (#4555 ) Next steps after DC2DC and Cluster doc improvements: - We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3 - We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced - We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed - We reorg the TOC having in more "logical" order: -- Deployment -- Administration -- Security -- Monitoring -- Troubleshooting - We adds parts in the TOC - We add toc per pages, using page-toc plugin - We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation - We improve swagger Internal Ref: - https://github.com/arangodb/planning/issues/1692 - https://github.com/arangodb/planning/issues/1655 - https://github.com/arangodb/planning/issues/1858 - https://github.com/arangodb/planning/issues/973 (partial fix) - https://github.com/arangodb/planning/issues/1498 (partial fix)	2018-02-28 12:23:19 +01:00
..
README.md	Doc - Replication Refactor - Part 1 (#4555 )	2018-02-28 12:23:19 +01:00

Doc - Replication Refactor - Part 1 (#4555 )

Next steps after DC2DC and Cluster doc improvements:

- We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3
- We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced
- We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed
- We reorg the TOC having in more "logical" order:
-- Deployment
-- Administration
-- Security
-- Monitoring
-- Troubleshooting
- We adds parts in the TOC
- We add toc per pages, using page-toc plugin
- We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation
- We improve swagger

Internal Ref:
- https://github.com/arangodb/planning/issues/1692
- https://github.com/arangodb/planning/issues/1655
- https://github.com/arangodb/planning/issues/1858
- https://github.com/arangodb/planning/issues/973 (partial fix)
- https://github.com/arangodb/planning/issues/1498 (partial fix)

2018-02-28 12:23:19 +01:00

README.md

Doc - Replication Refactor - Part 1 (#4555 )

2018-02-28 12:23:19 +01:00

README.md

HTTP Interface for AQL User Functions Management

AQL User Functions Management

This is an introduction to ArangoDB's HTTP interface for managing AQL user functions. AQL user functions are a means to extend the functionality of ArangoDB's query language (AQL) with user-defined JavaScript code.

For an overview of how AQL user functions and their implications, please refer to the Extending AQL chapter.

The HTTP interface provides an API for adding, deleting, and listing previously registered AQL user functions.

All user functions managed through this interface will be stored in the system collection _aqlfunctions. Documents in this collection should not be accessed directly, but only via the dedicated interfaces.

@startDocuBlock post_api_aqlfunction

@startDocuBlock delete_api_aqlfunction

@startDocuBlock get_api_aqlfunction