Basically for any metadata persistence function,
1) you should firstly define a interface say SomeService
interface SomeService {
void doSomeThing();
}
2) Then you need to implement the interface for different kind of storeage
type say memory (test purpose only), jdbc and mongodb, and bind the
implementation to interface in different MetadataStore module.
3) When you call @Inject SomeService, eagle server would inject the
configured type of implementation instance.
So:
1) As to your first question, I think it's YES, we currently only implement
memory-based store, but leave jdbc/mongodb later, if you would like to
contribute, I think you could do it.
2) As to your second question, I think it maybe NOT SURE, IMetadataDao is
only for alert related metadata only, if you would to extend alert related
metadata then it should be ok, if not, please define another interface and
bind in related storage module.
Please let me know if you have any more concern.
- Hao
On Thu, Aug 25, 2016 at 12:30 AM, Chang Chen <baibaic...@gmail.com> wrote:
> Hi Edward
>
> Do you mean implement SiteEntityEntityServiceJDBCImpl
> and ApplicationEntityJDBCImpl, so that we can bind them in
> JDBCMetadataStore? i.e.
>
> bind(SiteEntityService.class).to(SiteEntityEntityServiceJDBCI
> mpl .class).in(Singleton.class);
>
> bind(ApplicationEntityService.class).to(ApplicationEntityJDBCImpl.
> class).in(Singleton.class);
> Right?
>
> If so, that looks like we need define an interface like IMetadataDao(or
> directly update this interface).
>
> Any Idea? And Please correct me if I am wrong
>
> Thanks
> Chang
>
>
> On Tuesday, August 23, 2016, Edward Zhang <yonzhang2...@apache.org> wrote:
>
> > Yes, SiteEntityEntityServiceMemoryImpl is not thread safe, we need make
> it
> > thread safe.
> > Also one thing to mention is memory implementation is only for testing
> > purpose, we should have JDBC service implementation.
> > In JDBCMetadataStore, we have not registered jdbc implementation module.
> > Besides Site, for application, we also need jdbc implementation.
> > If you are interested, please help with it.
> >
> > Thanks
> > Edward
> >
> > On Mon, Aug 22, 2016 at 6:57 AM, Chang Chen <baibaic...@gmail.com
> > <javascript:;>> wrote:
> >
> > > Hi
> > >
> > > I am not very familiar with CompletableFuture, but highly suspect
> > > SiteResource isn't thread safe.
> > >
> > > Its member functions(i.e. createSite, getSiteBySiteId) could be called
> > > concurrently, and each member function run its callback via
> > > CompletableFuture. This requires SiteEntityEntityServiceMemoryImpl
> > thread
> > > safe, but it's not , because siteId2EntityMap is HashMap.
> > >
> > >
> > > Thanks
> > > Chang
> > >
> >
>
