Open Deric-W opened 1 year ago
Hi, thanks for the report! My understanding is that the intention was to support this use case and provide type-safe access to Order
subclasses via findAll(…)
, get(…)
and so on, so this seems to be a bug.
As a workaround (and to avoid filtering in Java) you can declare custom repository interfaces with that findAll(…)
method for each of your Order
subclasses that extends Spring's Repository
as shown in the Salespoint reference documentation. If you need a method query method several times, you can create a base interface and annotate it with @NoReposityBean
.
@NoRepositoryBean // suppress creation of bean, because T is unknown here
public interface BaseOrderRepository<T extends Order> extends Repository<T, OrderIdentifier> {
Page<T> findAll(Pageable pageable);
}
public interface ProductOrderRepository extends BaseOrderRepository<ProductOrder> {
}
public interface CustomerOrderRepository extends BaseOrderRepository<CustomerOrder> {
}
… the intention was to support this use case and provide type-safe access to Order subclasses via
findAll(…)
,get(…)
and so on, so this seems to be a bug …
I need to correct my statement after talking to @odrotbohm – supporting this use case was not intended. In Salespoint, you must always use either the stock Order
or one subclass of Order
. Mixing them or with more than one subclass, a lot of assumptions in OrderManagement
will break and type-safety issues arise.
There are a lot of reasons that this use case isn't supported. While in theory, it would be possible to support this in the framework, it would make the standard case – using just the stock Order
– a lot harder to use. Another one is that most often, you can create a simpler, equivalent design that doesn't depend on multiple Order
subclasses.
For example, in your case, you could either
1) use only the stock Order
and rely on the orders
association in your Customer
class, or
2) stick with just CustomerOrder
with the optional Customer
attribute, where absence means it is a product order. In this case, the orders
association in Customer
is redundant.
However, this can be improved in the documentation because this design constraint isn't mentioned.
Hi, I tried creating two Subclasses of
Order
and storing them in separateOrderManagement<T>
with specific types. CallingOrderManagement<T>::findAll(Pageable.unpaged())
yields aPage
containing all orders, regardless of type or order management.Is this use case not supported?
ProductOrder.java CustomerOrder.java OrderDataInitializer.java