This is an automated email from the ASF dual-hosted git repository.
ntimofeev pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cayenne.git
The following commit(s) were added to refs/heads/master by this push:
new 9044f156d Update main docs
9044f156d is described below
commit 9044f156d7303979b4b2ab6070b843a33fab09f7
Author: stariy95 <stari...@gmail.com>
AuthorDate: Wed Dec 6 17:02:15 2023 +0400
Update main docs
---
.../cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/setup.adoc | 2 +-
.../cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/customize.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part2/objectContext.adoc | 2 +-
.../cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/starting.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/setup.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/setup.adoc
index fbff2689c..2a57d838e 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/setup.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/setup.adoc
@@ -32,7 +32,7 @@ include::../var.adoc[]
|4.2
|Java 1.8 or newer
-|Release Candidate
+|Stable
|4.1
|Java 1.8 -- Java 17
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/customize.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/customize.adoc
index 7afde326d..ee0fd53e4 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/customize.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/customize.adoc
@@ -22,7 +22,7 @@ The services are configured in special Java classes called
"modules". Each modul
The discussion later in this chapter demonstrates a standalone DI container.
But keep in mind that Cayenne already has a built-in Injector, and a set of
default modules. A Cayenne user would normally only use the API below to write
custom extension modules that will be loaded in that existing container when
creating CayenneRuntime. See "Starting and Stopping CayenneRuntime" chapter for
an example of passing an extension module to Cayenne.
-Cayenne DI probably has ~80% of the features expected in a DI container and
has no dependency on the rest of Cayenne, so in theory can be used as an
application-wide DI engine. But it's primary purpose is still to serve Cayenne.
Hence there are no plans to expand it beyond Cayenne needs. It is an ideal
"embedded" DI that does not interfere with Spring, Guice or any other such
framework present elsewhere in the application.
+Cayenne DI probably has ~80% of the features expected in a DI container and
has no dependency on the rest of Cayenne, so in theory can be used as an
application-wide DI engine. But its primary purpose is still to serve Cayenne.
Hence there are no plans to expand it beyond Cayenne needs. It is an ideal
"embedded" DI that does not interfere with Spring, Guice or any other such
framework present elsewhere in the application.
===== DI Bindings API
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/objectContext.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/objectContext.adoc
index 7ae7df459..6f96447c2 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/objectContext.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/objectContext.adoc
@@ -194,7 +194,7 @@ ObjectContext parent = runtime.newContext();
ObjectContext nested = runtime.newContext(parent);
----
-From here, a nested context operates just like a regular context (you can
perform queries, create and delete objects, etc.). The only difference is that
commit and rollback operations can either be limited to synchronization with
the parent, or cascade all the way to the database:
+From here, a nested context operates just like a regular context (you can
perform queries, create and delete objects, etc...). The only difference is
that commit and rollback operations can either be limited to synchronization
with the parent, or cascade all the way to the database:
[source, java]
----
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/starting.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/starting.adoc
index 2bc270ea6..bc546dbde 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/starting.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/starting.adoc
@@ -104,7 +104,7 @@ When the application runs, all HTTP requests matching the
filter url-pattern hav
[source, java]
----
- ObjectContext context = BaseContext.getThreadObjectContext();
+ ObjectContext context = DataContext.getThreadObjectContext();
----
Of course, the ObjectContext scope and other behavior of the Cayenne runtime
can be customized via dependency injection. For this, another filter init
parameter called "extra-modules" is used. "extra-modules" is a comma- or
space-separated list of class names, with each class implementing Module
interface. These optional custom modules are loaded after the the standard
ones, which allows users to override all standard definitions.
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc
index 6ef34326f..73fee135d 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc
@@ -21,7 +21,7 @@ include::../var.adoc[]
An ORM system consists of three parts: database, OR mapping and persistent
Java classes. These parts always need to be kept in sync with each other for
the application to work. "DB-first" flow is a common and practical approach to
synchronization that assumes the database to be the master source of the
metadata, with other two parts synchronized from the DB as the schema evolves.
Cayenne provides a number of tools to automate and control it. Here is how
"DB-first" flow is typically implemented:
-- A SQL migrations framework is used to bring a local DB to a certain version.
This is outside of the scope of Cayenne and is done with a third-party tool,
such as Liquibase or Flyway.
+- A SQL migrations framework is used to bring a local DB to a certain version.
This is outside the scope of Cayenne and is done with a third-party tool, such
as Liquibase or Flyway.
- OR mapping model (Cayenne XML files) are synchronized with the state of the
database using `"cdbimport"` tool provided by Cayenne.
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc
index fdac23aff..95ac54b38 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc
@@ -15,7 +15,7 @@
[[re-modeler]]
=== Reverse Engineering in Cayenne Modeler
-Alternative approach to using <<cdbimport>> is doing reverse engineering from
<<CayenneModeler Application, CayenneModeler>>. Currently modeler GUI doesn't
support all features of ant/maven tasks but it suffice for general DB import.
Especially it's a good place to quickly start working on your data model.
+Alternative approach to using <<cdbimport>> is doing reverse engineering from
<<CayenneModeler Application, CayenneModeler>>.
You can find reverse engineering tool in dataMap view on *DbImport Tab*.
