Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Jakarta Data Proposal
Hey David,
The first one is the closest.

But instead of only annotation, it has an abstraction such as an interface.

In a simple sample where we have a Server entity, the Jakarta Data will provide a couple of standard annotations to any source system such as Jakarta Persistence or Jakarta NoSQL.
Besides an interface to abstract any data source:

@Entity
public class Server {

    @Id
    private Long id;

    private String name;

    private String version;
}

public interface ServerRepository extends Repository<Server, Long> {

    List<Server> findByVersion(String version);
}

After it, these abstractions will be injectable into any source implementation.

@ApplicationScoped
public class ServerService {

    @Inject
    private ServerRepository repository;

    public void logServers(String version) {
        List<Server> servers = repository.findByVersion(version);
        //do something
    }
}

In the first version, the goal is to push approaches that are data agonists, such as DDD.
Then we can go deeper on it, such as Domain Event, Aggregator Root, CQRS, Event Sourcing, etc.

On Fri, May 20, 2022 at 8:07 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
On May 18, 2022, at 2:04 AM, Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:

On Mon, May 16, 2022 at 11:24 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
 
Is the initial goal to create a repository interface or is it bigger than that?  Can you tell me is the goal to create an abstraction over JPA and NoSQL or are you looking to create separate specifications, one specific for JPA and one for specific for NoSQL?

 The goal is to create a spec to unify these data sources, such as Spring Data or Micronaut Data. We also can talk about the Microprofile Rest client of one of these implementations as well.

I'm trying to map out the spec relationships/dependencies we're intending to create.  Which is closer?

 - Jakarta Data would hold common annotations like the Common Annotations spec and have no dependency on Jakarta NoSQL, Jakarta Persistence.  Jakarta NoSQL, Jakarta Persistence will have a dependency on Jakarta Data and consume these common annotations. Like Commons Annotations, the TCK would be very thin.  The real requirements and TCK tests for those annotations would be decided by the respective users, Jakarta NoSQL and Jakarta Persistence.

 - Jakarta Data is an abstraction on top of Jakarta NoSQL, Jakarta Persistence and have a dependency on Jakarta NoSQL and Jakarta Persistence.  Jakarta NoSQL, Jakarta Persistence will not have a dependency on Jakarta Data.  The requirements and TCK tests that pertain to abstractions over Jakarta NoSQL & Jakarta Persistence will go in Jakarta Data.  To release, Jakarta Data will need compliant implementations of both Jakarta NoSQL and Jakarta Persistence as well as a compliant implementation of Jakarta Data.


-David

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec


--
Otávio Santana

Back to the top