buschmais/extended-objects

eXtended Objects - Lightweight and flexible datastore mapping of Java domain objects

Lars Martin

@CrystalMethod

will have a look, mavenBundle() tries to resolve dependencies via local/remote Maven repository but not via same Maven reactor build, an option would be to use reference: protocol as shown in in the last of the configuration

https://github.com/buschmais/extended-objects/blob/master/impl/src/test/java/com/buschmais/xo/impl/test/bootstrap/osgi/OSGiTestCase.java

Lars Martin

@CrystalMethod

@DirkMahler please verify the opened PR #152 as resolution for #151

Dirk Mahler

@DirkMahler

Thanks a lot!

Lars Martin

@CrystalMethod

hmm, Eclipse complains about incompatible return types in https://github.com/buschmais/extended-objects/blob/master/impl/src/main/java/com/buschmais/xo/impl/proxy/repository/composite/ResultOfMethod.java

orig:

protected AbstractInstanceManager<?, XOManager> getInstanceManager(SessionContext sessionContext)

w/o errors:

protected AbstractInstanceManager<?, Entity> getInstanceManager(SessionContext sessionContext)

Dirk Mahler

@DirkMahler

Will fix it. Interesting that neither Maven nor IntelliJ complain about that.

Lars Martin

@CrystalMethod

#141 :+1:

Dirk Mahler

@DirkMahler

On the way home (on the tram...) I made a prototype for datastore specific repositories - feels good!

While thinking about the stuff I missed the station where had to change the tram...

Dirk Mahler

@DirkMahler

@CrystalMethod A first draft for datastore specific repositories is committed and pushed (#153). RepositoryTest illustrates usage of DatastoreSpecificRepository which extends from Neo4jRepository and Neo4jRepositoryImpl is the datastore specific implementation. What do you think?

Sebastian Schmid

@SchmidSebastian

Just changed my code to use the new annotations brought by #141... Great work!

Lars Martin

@CrystalMethod

@DirkMahler #153 - great work, I'm in the process to update xo-tinkerpop in the first step - one question though: would it be possible to extend Neo4jRepository in a way to make use of generics:

@Repository
public interface MovieRepository extends Neo4jRepository<Movie> {
}

MovieRepositry repository = xoManager.getRepository(MovieRepository.class);
Result<Movie> movies = repository.findAll();

Lars Martin

@CrystalMethod

repository integration into xo-tinkerpop finished - dead easy

Dirk Mahler

@DirkMahler

@CrystalMethod Generic support should be possible - but it seems to me that the repository itself is responsible to detect its type parameter. Possibly there could be some utility functionality provided by XO to make als this generic type stuff easier

Lars Martin

@CrystalMethod

anyway, the repository stuff looks great - improvements can be made later on

Lars Martin

@CrystalMethod

wow, using Gremlin one can utilize XO for complicated calculations

Long result = xoManager.createQuery("2 + 1", Long.class).execute().getSingleResult();

:smile:

Dirk Mahler

@DirkMahler

:clap:

@CrystalMethod Just working on an example for generic repositories using a type parameter. Let's see if I can push it tomorrow.

Lars Martin

@CrystalMethod

@DirkMahler in xo-mongodb I have an issue to implement DatastoreEntityManager.deleteEntity(Entity) when using separated collections per type (document) b/c the given entity is plain JSON that does not have any link to the underlying document collection, thus cant know which collection the document to delete from; I see two options: a) "hidden" JSON attribute to store the collection info at creation time b) extend deleteEntity(Entity) to also pass metatype information - comparable with createEntity(...)

that problem didnt exist yet because in the current implementation all documents are stored in the same collection

Lars Martin

@CrystalMethod

there might be option c) to cache a mapping (document<>collection) of all documents in theDatastoreEntityManager instance

Lars Martin

@CrystalMethod

so what are the chances to extend the spi (option b)? do you see any other solution?

Dirk Mahler

@DirkMahler

@CrystalMethod Just pushed an example for a generic/typed Neo4j repository

Lars Martin

@CrystalMethod

thx, will have a look at it

Dirk Mahler

@DirkMahler

BTW: It has been a good idea to use gitter!

@CrystalMethod Regarding mongo-db: I think the best way is to pass the entity metadata via the SPI

Dirk Mahler

@DirkMahler

@CrystalMethod To make the interface consistent also flush should obtain the metadata

Can you can create an issue?

Dirk Mahler

@DirkMahler

Do you need the metadata for getEntityId/getRelationId?

Lars Martin

@CrystalMethod

not yet, currently I presume the default "_id" attribute but in Mongo you can define normal attributes like "name" as Id; so I will introduce an @Id annotation and then the metadata is going to be required

Dirk Mahler

@DirkMahler

The problem is that it cold become quite expensive to pass the metadata at this point

Lars Martin

@CrystalMethod

something as follows:

@Document("person")
interface Person {
    @Id
    String getName()
    void setName(String);  
}

Dirk Mahler

@DirkMahler

my preferred solution would be the the entity represention used by the datastore keeps an object containing all the relevant attributes

and just returns it

Lars Martin

@CrystalMethod

you mean a small wrapper around the native datastore type to hold additional attributes?

Dirk Mahler

@DirkMahler

exactly

We should create a dev guide...

Lars Martin

@CrystalMethod

:+1:

Lars Martin

@CrystalMethod

Why does XO prohibit arrays of primitive types as member of entities? Neo4j supports array properties (http://docs.neo4j.org/chunked/stable/graphdb-neo4j-properties.html) and its one of MongoDBs key features.

Example:

@Document
public interface Article {
    // ...
    Set<String> getTags();
}

Lars Martin

@CrystalMethod

the solution to wrap native types to store additional attributes works quite well in xo-mongo

Lars Martin

@CrystalMethod

my rewriting of xo-mongo with the new repo feature feels really good, relations are stored as DBRefs

Dirk Mahler

@DirkMahler

#154 is more difficult than I thought - due to the dynamic types of entities at runtime it is quite expensive to determine the metadata on each request of getId(), flush() or possibly delete(). My prefered solution would be to cache all these things in the entity/relation representations of the datastore implementation.

Regarding collections of primitive types - that's an "accident", we can make it work ;-)

Lars Martin

@CrystalMethod

that’s how I’ve done it in xo-mongo: wrap native datastore types and add additional info - currently I don’t need any modificatio in the SPI

Dirk Mahler

@DirkMahler

Then I'll close #154 adding an explanation and a hint to cache the required information in a datastore specific wrapper type

Lars Martin

@CrystalMethod

is there any chance to determine the corresponding entity type in DatastoreMetadataFactory.createPropertyMetadata(PropertyMethod propertyMethod)?

Lars Martin

@CrystalMethod

currently I’m using

Class<?> declaringClass = propertyMethod.getAnnotatedElement().getDeclaringClass();

but I’m not sure if this is the best approach

Lars Martin

@CrystalMethod

I am obviously asking because I have to manually implement index creation and XO only supports one indexed property but in xo-mongodb I have to support multiple indexed fields as well as multiple (compound) indexes declared for types; my current strategy is to extend createPropertyMetadata in the way to also store index information (if available) in the property metadata to be created and to finally create the index in Datastore.init(Map<Class<?>, TypeMetadata> registeredMetadata)

Lars Martin

@CrystalMethod

Never mind - in Datastore.init() I have access to both: TypeMetadata + PropertyMetadata (via. getProperties())

Where communities thrive

People

Repo info

Activity