Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 15 2014 16:43

    DirkMahler on master

    #133 don't use classes of Java 8 (compare)

  • Nov 10 2014 16:38

    DirkMahler on master

    #133 don't use classes of Java 8 (compare)

  • Nov 09 2014 12:00

    DirkMahler on master

    #133 introduce a cacheable Comp… (compare)

  • Nov 07 2014 18:16

    DirkMahler on master

    #153 added support for generic … Merge remote-tracking branch 'o… updated javadoc maven plugin (compare)

  • Nov 07 2014 17:18

    DirkMahler on master

    #133 reduce reflection calls (compare)

  • Nov 07 2014 17:03

    DirkMahler on master

    #133 avoid runtime checking of … moved m2e config to a separate … Merge remote-tracking branch 'o… (compare)

  • Nov 06 2014 09:00
    DirkMahler commented #154
  • Nov 06 2014 09:00
    DirkMahler closed #154
  • Nov 06 2014 08:28
    DirkMahler closed #131
  • Nov 06 2014 08:28
    DirkMahler commented #131
  • Nov 06 2014 08:24
    DirkMahler labeled #131
  • Nov 06 2014 08:24
    DirkMahler assigned #157
  • Nov 06 2014 08:24
    DirkMahler labeled #157
  • Nov 04 2014 17:01
    CrystalMethod opened #157
  • Nov 03 2014 07:12
    CrystalMethod opened #156
  • Oct 31 2014 07:26
    DirkMahler closed #155
  • Oct 31 2014 07:26

    DirkMahler on master

    transaction might be null Merge pull request #155 from SM… (compare)

  • Oct 31 2014 07:06
    CrystalMethod opened #155
  • Oct 30 2014 08:29
    CrystalMethod opened #154
  • Oct 29 2014 19:16

    DirkMahler on master

    #153 added support for direct u… #153 extended XOSession interfa… (compare)

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
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())