v6.0.0alpha5

Added

• Added the Action-Domain-Responder (ADR) HTTP stack under Phalcon\ADR, an alternative to MVC that splits request handling into three focused roles: an Action (one invokable class per route) drives a Domain (your business logic, which returns a Phalcon\ADR\Payload\Payload and never touches HTTP) and hands the result to a Responder that turns it into a response. Phalcon\ADR\Application::handle() routes the request with the convention-based Phalcon\ADR\Router\Router - the HTTP method, resource and optional operation resolve the Action class (e.g. GET /invoices/list maps to MyApp\Action\Invoices\GetInvoicesList), with no route table - writes the matched positional attributes onto the request, and runs the Action through Phalcon\ADR\Dispatcher, which resolves it from the container and wraps it in a middleware pipeline (Phalcon\ADR\Middleware\CorsMiddleware, MethodOverrideMiddleware, RequestIdMiddleware and TimingMiddleware ship built-in). The Action reads request data through the extendable Phalcon\ADR\Input\Input bag and returns a response built by a responder - Phalcon\ADR\Responder\JsonResponder, TextResponder, RedirectResponder, StatusResponder and the composable ChainResponder/FormatResponder - each mapping the payload's Phalcon\ADR\Payload\Status to an HTTP status via Phalcon\ADR\Responder\StatusMapper. Any escaping Throwable is turned into a response by the always-wired Phalcon\ADR\ErrorResponder, and Phalcon\ADR\Emitter\SapiEmitter sends it to the client. Phalcon\ADR\Front\HttpFront - a Phalcon\Contracts\Front\FrontController following the front-interop contract - boots the whole stack with a single run(), and Phalcon\ADR\Container\AdrProvider registers every service. Because route attributes are positional, Phalcon\Http\Request\Bag\AbstractBag now accepts integer keys alongside string keys. Contracts live under Phalcon\Contracts\ADR. #17341 [doc]
• Added request attributes support to Phalcon\Http\Request in preparation for the future HTTP layer redesign: Phalcon\Http\Request::getAttributes() returns a Phalcon\Http\Request\Bag\AttributeBag, a mutable, string-keyed bag of arbitrary application-defined values attached to the request during its lifecycle (router, dispatcher, security components etc.). Unlike the superglobal-backed request data, the bag always starts empty; it is created on first access and the same instance is returned on every call. The bag is backed by the new Phalcon\Http\Request\Bag\AbstractBag base - get()/has()/set()/remove()/all(), the typed readers getInt()/getString()/getBool()/getFloat()/getArray() for cast-with-default access, and ArrayAccess/Countable/IteratorAggregate - which future request bags will extend. Writing with a null key (the $bag[] = ... append form) throws the new Phalcon\Http\Request\Exceptions\NullKeyException, since bag elements are always string-keyed. #17367 [doc]

Fixed

• Fixed Phalcon\Mvc\Model ignoring attributes registered with skipAttributes(), skipAttributesOnCreate() and skipAttributesOnUpdate(), so a skipped column was emitted in the generated INSERT/UPDATE (breaking, for instance, inserts into a table with a MySQL generated column). The skip list is keyed with null values, which isset() reports as absent, so every skipped attribute read as not registered; the checks in doLowInsert(), doLowUpdate() and the not-null validation now use array_key_exists(). #17382 [doc]
• Fixed Phalcon\Mvc\Model inserting a literal null for a column the database can supply a value for, instead of the DEFAULT keyword (or omitting the column on an adapter without DEFAULT support, such as SQLite). A nullable column carrying no explicit default is registered in the metadata default values with a null value, which the isset() check in doLowInsert() read as absent; it now uses array_key_exists(). This makes inserts work against a MySQL GENERATED ALWAYS AS (...) STORED column, which rejects an explicit null with SQLSTATE[HY000]: General error: 3105 but accepts DEFAULT. #17382 [doc]