Added more docs

Author: JohannesRabauer

docs/modules/ROOT/pages/known-issues.adoc

@@ -1,4 +1,39 @@
 = Known issues
 
+== Lazy references
 
-//TODO
+One of the core features of EclipseStore is its https://docs.eclipsestore.io/manual/storage/loading-data/lazy-loading/index.html[Lazy references].
+Unfortunately this requires our library to implement some kind of proxy.
+That's something that takes a lot of effort to implement in our {product-name}.
+
+We created https://github.com/xdev-software/spring-data-eclipse-store/issues/31[an issue] for that but right now we *do not support Lazy references*.
+
+== Query annotations
+
+In Spring-Data-JPA you can write a Query over methods of repositories like this:
+
+[source,java,title="From https://github.com/spring-projects/spring-petclinic/blob/main/src/main/java/org/springframework/samples/petclinic/owner/OwnerRepository.java[spring-petclinic]"]
+----
+@Query("SELECT ptype FROM PetType ptype ORDER BY ptype.name")
+List<PetType> findPetTypes();
+----
+
+We created https://github.com/xdev-software/spring-data-eclipse-store/issues/32[an issue] for that but right now we *do not support Query annotations*.
+
+== Data changes
+
+There are two basic ways to keep your data up to date.
+
+=== Structural
+
+As with most projects, data that needs persisting changes over time.
+In EclipseStore that's handled through https://docs.eclipsestore.io/manual/storage/legacy-type-mapping/index.html[Legacy Type Mapping].
+
+That consists of https://docs.eclipsestore.io/manual/storage/legacy-type-mapping/index.html#_automatic_mapping[Automatic Mapping] through EclipseStores internal heuristic and https://docs.eclipsestore.io/manual/storage/legacy-type-mapping/index.html#explicit-mapping[Explicit Mapping] by the user.
+
+=== Values
+
+There is a library to version your data in the store called https://github.com/xdev-software/micro-migration[XDEV MicroMigration].
+This helps you keep your data up to date regardless of the current version.
+
+We created https://github.com/xdev-software/spring-data-eclipse-store/issues/33[an issue] for that but right now we *do not support XDEVs MicroMigration*.

docs/modules/ROOT/pages/migration.adoc

@@ -11,21 +11,26 @@ mvn org.openrewrite.maven:rewrite-maven-plugin:run \
 -Drewrite.activeRecipes=software.xdev.spring.data.eclipse.store.JpaMigration
 ----
 
+[CAUTION]
+====
+Since {product-name} can't handle ``@Query``-Annotations, these annotations are getting removed by the Rewrite-Recipe.
+====
+
 == Data
 
 To import data from different data sources like JPA, you can simply let the ``EclipseStoreDataImporterComponent`` get injected and then call ``importData()``.
 This reads all instances of ``EntityManagerFactory``, creates EclipseStoreRepositories for it and then imports that data.
 This can take quite some time if you have a lot of data.
 
-[source,java,title="Maven"]
+[source,java]
 ----
-	@Autowired
-	private EclipseStoreDataImporterComponent eclipseStoreDataImporter;
+@Autowired
+private EclipseStoreDataImporterComponent eclipseStoreDataImporter;
 
-	void importDataFromJpaToEclipseStore()
-	{
-		final List<SimpleEclipseStoreRepository<?, ?>> repositories = this.eclipseStoreDataImporter.importData();
-	}
+void importDataFromJpaToEclipseStore()
+{
+    final List<SimpleEclipseStoreRepository<?, ?>> repositories = this.eclipseStoreDataImporter.importData();
+}
 ----
 
 After that you can change your JpaRepositories to EclipseStoreRepositories and you're done.

docs/modules/ROOT/pages/working-copies.adoc

@@ -7,8 +7,9 @@ image::../images/WorkingCopy_1.svg[Native behavior of EclipseStore]
 If you e.g. change the address of a person, the changed address is already in your data model, *even before storing* this person.
 This is very different from the behavior a Spring user expects.
 
+image::../images/WorkingCopy_2.svg[Behavior of EclipseStore with Spring-Data-Eclipse-Store]
+
 With {product-name} every time an object is loaded from the datastore, a working copy of that object (or rather the object tree) is created and returned to the user.
 Therefore, the user can make the changes on the working copy without any changes to the actual data model.
 The changes are only persisted after calling ``save`` on a repository.
 
-image::../images/WorkingCopy_2.svg[Behavior of EclipseStore with Spring-Data-Eclipse-Store]