This is an automated email from the ASF dual-hosted git repository.
aadamchik pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cayenne.git
commit 465d5129e8266d7eb4155e5cd294e446ad44318b
Author: Eduard <5306834+kaga...@users.noreply.github.com>
AuthorDate: Tue Jul 11 03:25:11 2023 +0300
Typos fixed in all `cayenne-guide` section.
---
.../src/docs/asciidoc/_cayenne-guide/part1/mapping.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part1/modeler.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part2/customize.adoc | 10 +++++-----
.../src/docs/asciidoc/_cayenne-guide/part2/lifecycle.adoc | 8 ++++----
.../src/docs/asciidoc/_cayenne-guide/part2/starting.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part2/tuning.adoc | 4 ++--
.../src/docs/asciidoc/_cayenne-guide/part4/filtering.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part4/introduction.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part4/revEngineering.adoc | 2 +-
.../src/docs/asciidoc/_cayenne-guide/part5/jCache.adoc | 2 +-
10 files changed, 18 insertions(+), 18 deletions(-)
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/mapping.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/mapping.adoc
index 90b28d59b..f8ad37814 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/mapping.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/mapping.adoc
@@ -34,7 +34,7 @@ DataMap are referenced by name in the root descriptor:
<map name="datamap"/>
----
-Map files are resolved by Cayenne by appending ".map.xml" extension to the map
name, and resolving the resulting string relative to the root descriptor URI.
The following sections discuss varios ORM model objects, without regards to
their XML representation. XML format details are really unimportant to the
Cayenne users.
+Map files are resolved by Cayenne by appending ".map.xml" extension to the map
name, and resolving the resulting string relative to the root descriptor URI.
The following sections discuss various ORM model objects, without regards to
their XML representation. XML format details are really unimportant to the
Cayenne users.
==== DataMap
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/modeler.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/modeler.adoc
index 9298ea5a7..049522b87 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/modeler.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part1/modeler.adoc
@@ -43,7 +43,7 @@ In advanced mode you can control almost all aspects of code
generation including
==== Modeling Generic Persistent Classes
-Normally each ObjEntity is mapped to a specific Java class (such as Artist or
Painting) that explicitly declare all entity properties as pairs of getters and
setters. However Cayenne allows to map a completly generic class to any number
of entities. The only expectation is that a generic class implements
org.apache.cayenne.DataObject. So an ideal candidate for a generic class is
CayenneDataObject, or some custom subclass of CayenneDataObject.
+Normally each ObjEntity is mapped to a specific Java class (such as Artist or
Painting) that explicitly declare all entity properties as pairs of getters and
setters. However Cayenne allows to map a completely generic class to any number
of entities. The only expectation is that a generic class implements
org.apache.cayenne.DataObject. So an ideal candidate for a generic class is
CayenneDataObject, or some custom subclass of CayenneDataObject.
If you don't enter anything for Java Class of an ObjEntity, Cayenne assumes
generic mapping and uses the following implicit rules to determine a class of a
generic object. If DataMap "Custom Superclass" is set, runtime uses this class
to instantiate new objects. If not, `org.apache.cayenne.CayenneDataObject` is
used.
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 f943b330a..32776683a 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
@@ -26,7 +26,7 @@ Cayenne DI probably has ~80% of the features expected in a DI
container and has
===== DI Bindings API
-To have a working DI container, we need three things: service interfaces and
classes, a module that describes service bindings, a container that loads the
module, and resolves the depedencies. Let's start with service interfaces and
classes:
+To have a working DI container, we need three things: service interfaces and
classes, a module that describes service bindings, a container that loads the
module, and resolves the dependencies. Let's start with service interfaces and
classes:
[source, Java]
----
@@ -150,7 +150,7 @@ binder.bind(Key.get(Service2.class,
"i2")).to(Service2Impl.class);
----
-Another types of confiuguration that can be bound in the container are lists
and maps. They will be discussed in the following chapters.
+Another types of configuration that can be bound in the container are lists
and maps. They will be discussed in the following chapters.
===== Service Lifecycle
@@ -176,7 +176,7 @@ can be created as instances of
`org.apache.cayenne.di.spi.DefaultScope` with sta
===== Overriding Services
-Cayenne DI allows to override services already definied in the current module,
or more commonly - some other module
+Cayenne DI allows to override services already defined in the current module,
or more commonly - some other module
in the the same container. Actually there's no special API to override a
service, you'd just bind the service key again
with a new implementation or provider. The last binding for a key takes
precedence. This means that the order of modules is important when configuring
a container.
The built-in Cayenne injector ensures that Cayenne standard modules are loaded
first, followed by optional user extension modules.
@@ -223,7 +223,7 @@ $ java -Dcayenne.server.contexts_sync_strategy=false ...
----
A second one is to contribute a property to
`o.a.c.configuration.DefaultRuntimeProperties.properties` map (see the next
section on how to do that).
-This map contains the default property values and can accept
application-specific values, overrding the defaults.
+This map contains the default property values and can accept
application-specific values, overriding the defaults.
Note that if a property value is a name of a Java class, when this Java class
is instantiated by Cayenne,
the container performs injection of instance variables. So even the
dynamically specified Java classes can use @Inject annotation to get a hold of
other Cayenne services.
@@ -242,7 +242,7 @@ DbAdapterDetector to a
`o.a.c.configuration.server.DefaultDbAdapterFactory.detec
----
public class MyDbAdapterDetector implements DbAdapterDetector {
public DbAdapter createAdapter(DatabaseMetaData md) throws SQLException {
- // check if we support this database and retun custom adapter
+ // check if we support this database and return custom adapter
...
}
}
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/lifecycle.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/lifecycle.adoc
index c8fb6925b..f6fdecce0 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/lifecycle.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/lifecycle.adoc
@@ -18,11 +18,11 @@ An application might be interested in getting notified when
a Persistent object
All this can be achieved by declaring callback methods either in Persistent
objects or in non-persistent listener classes defined by the application
(further simply called "listeners"). There are eight types of lifecycle events
supported by Cayenne, listed later in this chapter. When any such event occurs
(e.g. an object is committed), Cayenne would invoke all appropriate callbacks.
Persistent objects would receive their own events, while listeners would
receive events from any objects.
-Cayenne allows to build rather powerful and complex "workflows" or
"processors" tied to objects lifecycle, especially with listeners, as they have
full access to the application evnironment outside Cayenne. This power comes
from such features as filtering which entity events are sent to a given
listener and the ability to create a common operation context for multiple
callback invocations. All of these are discussed later in this chapter.
+Cayenne allows to build rather powerful and complex "workflows" or
"processors" tied to objects lifecycle, especially with listeners, as they have
full access to the application environment outside Cayenne. This power comes
from such features as filtering which entity events are sent to a given
listener and the ability to create a common operation context for multiple
callback invocations. All of these are discussed later in this chapter.
==== Types of Lifecycle Events
-Cayenne defines the following 8 types of lifecycle events for which callbacks
can be regsitered:
+Cayenne defines the following 8 types of lifecycle events for which callbacks
can be registered:
[#lifecycleEvent.table.table-bordered]
.Lifecycle Event Types
@@ -81,7 +81,7 @@ As `onNewOrder()` is already declared in the mapping, it does
not need to be reg
As a rule callback methods do not have any knowledge of the outside
application, and can only access the state of the object itself and possibly
the state of other persistent objects via object's own ObjectContext.
-NOTE: Validation and callbacks: There is a clear overlap in functionality
between object callbacks and `DataObject.validateForX()` methods. In the future
validation may be completely superceeded by callbacks. It is a good idea to use
"validateForX" strictly for validation (or not use it at all). Updating the
state before commit should be done via callbacks.
+NOTE: Validation and callbacks: There is a clear overlap in functionality
between object callbacks and `DataObject.validateForX()` methods. In the future
validation may be completely superseded by callbacks. It is a good idea to use
"validateForX" strictly for validation (or not use it at all). Updating the
state before commit should be done via callbacks.
==== Callbacks on Non-Persistent Listeners
@@ -158,7 +158,7 @@ void postRemove(Persistent object) {
[source, Java]
----
-// similar example with multipe annotations on a single method
+// similar example with multiple annotations on a single method
// each matching just one entity
@PostPersist(MyEntity1.class)
@PostRemove(MyEntity1.class)
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 3683c33ea..31ea8f610 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
@@ -78,7 +78,7 @@ When the projects are merged, the following rules are applied:
==== Web Applications
-Web applications can use a variety of mechanisms to configure and start the
"services" they need, Cayenne being one of such services. Configuration can be
done within standard servlet specification objects like Servlets, Filters, or
ServletContextListeners, or can use Spring, JEE CDI, etc. This is a user’s
architectural choice and Cayenne is agnostic to it and will happily work in any
environment. As described above, all that is needed is to create an instance of
ServerRuntime somewhere [...]
+Web applications can use a variety of mechanisms to configure and start the
"services" they need, Cayenne being one of such services. Configuration can be
done within standard servlet specification objects like Servlets, Filters, or
ServletContextListeners, or can use Spring, JEE CDI, etc. This is a user's
architectural choice and Cayenne is agnostic to it and will happily work in any
environment. As described above, all that is needed is to create an instance of
ServerRuntime somewhere [...]
Still Cayenne includes a piece of web app configuration code that can assist
in quickly setting up simple Cayenne-enabled web applications. We are talking
about CayenneFilter. It is declared in web.xml:
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/tuning.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/tuning.adoc
index 7349e05e3..888e82205 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/tuning.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part2/tuning.adoc
@@ -101,7 +101,7 @@ different prefetches.
`<<sqlselect,SQLSelect>>` query supports "JOINT" and "DISJOINT_BY_ID". It does
not work with "DISJOINT", as the query does not provide
enough information to Cayenne to build dependent prefetch queries. So
"DISJOINT" will result in exception. "JOINT"
prefetching requires a bit of effort shaping the SQL to include the right
columns in the result and label them properly
-to be convertable into object properties. The main rules to follow are:
+to be convertible into object properties. The main rules to follow are:
* Include _all_ columns from the root entity and every prefetched entity.
* Label each prefetched entity columns as "dbRelationship.column".
@@ -138,7 +138,7 @@ Converting result set data to Persistent objects and
registering these objects i
operation comparable to the time spent running the query (and frequently
exceeding it). Internally Cayenne builds the result as a list of DataRows,
that are later converted to objects. Skipping the last step and using data in
the form of DataRows can significantly increase performance.
-DataRow is a simply a map of values keyed by their DB column name. It is a
ubiqutous representation of DB data used internally by Cayenne.
+DataRow is a simply a map of values keyed by their DB column name. It is a
ubiquitous representation of DB data used internally by Cayenne.
And it can be quite usable as is in the application in many cases. So
performance sensitive selects should consider
DataRows - it saves memory and CPU cycles. All selecting queries support
DataRows option, e.g.:
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/filtering.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/filtering.adoc
index 39dc4cfe6..64f8da75e 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/filtering.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part4/filtering.adoc
@@ -97,7 +97,7 @@ Cayenne supports combination of different schemas and
catalogs, and it filters d
</dbimport>
----
-In the example above, Cayenne reverse engineering process contains three
catalogs named as shop_01, shop_02 and shop_03, each of wich has their own
schemas. Cayenne will load all data only from the declared catalogs and schemas.
+In the example above, Cayenne reverse engineering process contains three
catalogs named as shop_01, shop_02 and shop_03, each of which has their own
schemas. Cayenne will load all data only from the declared catalogs and schemas.
If you want to load everything from database, you could simply declare catalog
specification alone.
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 187dfaf6a..6ef34326f 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
@@ -23,7 +23,7 @@ An ORM system consists of three parts: database, OR mapping
and persistent Java
- 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.
-- OR mapping model (Cayenne XML files) are synchronized with the state of the
database using `"cdbimport"` tool provdied by Cayenne.
+- OR mapping model (Cayenne XML files) are synchronized with the state of the
database using `"cdbimport"` tool provided by Cayenne.
- Object layer of the OR mapping model is customized to the developer liking,
usually via CayenneModeler. Subsequent runs of `"cdbimport"` will not override
any customizations that you make.
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 b48d784de..fdac23aff 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 aproach 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>>. 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.
You can find reverse engineering tool in dataMap view on *DbImport Tab*.
diff --git
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part5/jCache.adoc
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part5/jCache.adoc
index c16d06a54..7b9d896e9 100644
---
a/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part5/jCache.adoc
+++
b/docs/asciidoc/cayenne-guide/src/docs/asciidoc/_cayenne-guide/part5/jCache.adoc
@@ -52,7 +52,7 @@ ServerRuntime.builder()
.contributeJCacheProviderConfig(binder,
"cache-config.xml"));
----
-Also JCache module supports contribution of preconfigured cache manager.
+Also JCache module supports contribution of pre-configured cache manager.
[source, java]
----
