mirror of https://gitee.com/bigwinds/arangodb
typos etc.
This commit is contained in:
parent
44262ecb2e
commit
cc42bdabf4
86
CHANGELOG
86
CHANGELOG
|
@ -1,56 +1,64 @@
|
|||
v2.5.0-alpha2 (2015-02-16)
|
||||
-------------------
|
||||
|
||||
* Simplify the entry to foxx
|
||||
* Simplify usage of Foxx
|
||||
|
||||
Thanks to our user feedback we learned that foxx is a powerful, yet rather complicated concept.
|
||||
With this release we tried to make it less complicated while keeping all it's strength.
|
||||
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
|
||||
With this release we tried to make it less complicated while keeping all its strength.
|
||||
That includes a rewrite of the documentation as well as some code changes as listed below:
|
||||
|
||||
* Moved Foxx applications to a different folder.
|
||||
|
||||
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
|
||||
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
|
||||
This caused some trouble as apps where cached based on name and version and updates did not apply.
|
||||
Hence the path on filesystem and the url to access had no relation to one another.
|
||||
Now the path on filesystem is identical to the url (except for slashes and the appended APP)
|
||||
* Moved Foxx applications to a different folder.
|
||||
|
||||
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
|
||||
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
|
||||
This caused some trouble as apps where cached based on name and version and updates did not apply.
|
||||
Hence the path on filesystem and the app's access URL had no relation to one another.
|
||||
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
|
||||
|
||||
* Rewrite of Foxx routing
|
||||
* Rewrite of Foxx routing
|
||||
|
||||
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
|
||||
This allows us to set the development mode per mountpoint without having to change pathes and hold
|
||||
apps at seperate locations.
|
||||
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
|
||||
This allows us to set the development mode per mountpoint without having to change pathes and hold
|
||||
apps at seperate locations.
|
||||
|
||||
* Foxx Development mode
|
||||
* Foxx Development mode
|
||||
|
||||
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
|
||||
This includes the deprecation of the javascript.dev-app-path parameter which is useless since 2.5
|
||||
Instead all apps are located at the same location production as well as development.
|
||||
But you can set specfic apps into development mode changeing their behaviour compared to
|
||||
production apps: They are rerouted from disc on any request, they ship more debug output on routes.
|
||||
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
|
||||
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
|
||||
Instead of having two separate app directories for production and development, apps now reside in
|
||||
one place, which is used for production as well as for development.
|
||||
Apps can still be put into development mode, changing their behavior compared to production mode.
|
||||
Development mode apps are still reread from disk at every request, and still they ship more debug
|
||||
output.
|
||||
|
||||
* Foxx install process
|
||||
* Foxx install process
|
||||
|
||||
Installing of foxxes has been a two step process: import them in arangodb and mount them on a
|
||||
specific mountpoint. These operations have been joined together. You install an app on one
|
||||
mountpoint, thats it. No fetch, mount, unmound, purge anymore.
|
||||
* Install: get your foxx up and running.
|
||||
* Uninstall: shut it down and erase it from disc.
|
||||
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
|
||||
specific mountpoint. These operations have been joined together. You can install an app at one
|
||||
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
|
||||
simplified to just:
|
||||
|
||||
* Foxx error output
|
||||
* install: get your Foxx app up and running
|
||||
* uninstall: shut it down and erase it from disk
|
||||
|
||||
Until 2.4 the errors produced by foxx where not optimal. If any they created only in internal
|
||||
stack trace and always returned with 'unable to parse manifest'.
|
||||
In 2.5 we made major improvements there, including a much more finegrained error output that
|
||||
helps you debug your foxxes. The error is now much closer to it's source and should help you
|
||||
track it down.
|
||||
Also we added the default handlers for unhandled errors in your foxxes.
|
||||
* You will get a nice internal error page whenever your foxx cannot be installed.
|
||||
* You will get a propper error message when having an unhandled error in your route.
|
||||
In production mode the messages above will NOT contain any information about your foxx internals
|
||||
and are save to be exposed to third party.
|
||||
In development mode the messages above will contain the stacktrace if available making it easier for
|
||||
your in-house devs to track down the errors in their application.
|
||||
* Foxx error output
|
||||
|
||||
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
|
||||
`unable to parse manifest` and contained only an internal stack trace.
|
||||
In 2.5 we made major improvements there, including a much more finegrained error output that
|
||||
helps you debug your Foxx apps. The error message printed is now much closer to its source and
|
||||
should help you track it down.
|
||||
|
||||
Also we added the default handlers for unhandled errors in Foxx apps:
|
||||
|
||||
* You will get a nice internal error page whenever your Foxx app is called but was not installed
|
||||
due to any error
|
||||
* You will get a proper error message when having an uncaught error appears in any app route
|
||||
|
||||
In production mode the messages above will NOT contain any information about your Foxx internals
|
||||
and are safe to be exposed to third party users.
|
||||
In development mode the messages above will contain the stacktrace (if available), making it easier for
|
||||
your in-house devs to track down errors in the application.
|
||||
|
||||
* added optimizer rule `propagate-constant-attributes`
|
||||
|
||||
|
|
Loading…
Reference in New Issue