Configuring and using 'external' PostgreSQL db instances in Qi4j

[michaelp]

Hi guys, 

For my application, I need to use one or more remote PostgreSQL database instances. My plan is to use a .properties file for each, containing all the database-specific properties (like url, username, password, etc.), and pass the corresponding Properties object to the Qi4j assembler. I have taken a look at SQL EntityStore and also Configure a Service, where it is mentioned that the .properties files must be placed in the same package where the service (in my case the PostgreSQL entity store service) is. This is not convenient in my case, as I would like the .properties files to be in a /conf folder within my application's directory structure, and be accessed from my Main class.

Since I am probably missing something, I'd like to ask for a more detailed example (or a pointer to some existing source code) of how to assemble the PostgreSQL entity store in an app, given that the actual database resides in a different server than the application code. 

Kind regards,

Michael

[Niclas Hedhman]

Hi Michael,

First of all, you are right that EntityStores are Services and are configured in the same way as any other service. BUT, Configuration itself is an Entity, which needs to be backed by an EntityStore. SO for (and only for) EntityStores there is a chicken-egg problem. This is solved by putting the Configuration of an EntityStore in a different Module (some of us prefer it to be in a Layer below "Infrastructure"), which has Visibility.module on its EntityStore, which is also configuration-free.

Secondly, the configuration properties file is purely for bootstrapping initial values, and technically not required after this initial bootstrapping. However, many people (you?) like to have configuration in such manner, and they simply use a MemoryEntityStore.

So, every Service Configuration uses the NAME of the service to locate the configuration properties. By default, the Name is the fully-qualified name of the class of the ServiceComposite interface. But you can set your own name in the bootstrap with the ServiceDeclaration.identifiedBy() method. But it needs to be on the classpath. So, if you put conf/ on the classpath and give any name you like, that name.properties will be looked up inside the conf/ directory.

Not sure what you mean by "actual database resides in a different server", as it is not really relevant at all, or I am missing something. The EntityStore abstraction is such that your app can't tell the difference.

Hope that helps

Niclas

--
You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

--
Niclas Hedhman, Software Developer
河南南路555弄15号1901室。
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug

[Paul Merlin]

Michael,

You should take a look at the SQLSupport Sample that show how to configure DataSources and SQLEntityStore.

Cheers

/Paul

[michaelp]

Thanks to both for your feedback and pointers given. 

Cheers, 

Michael

[michaelp]

The problem was resolved, please disregard the last two messages. Apologies for spamming!

M.

On Tuesday, September 30, 2014 4:19:04 PM UTC+3, michaelp wrote:

Correct attachment with .properties files.

[Niclas Hedhman]

Glad you found it. Without diving into the details, my guess is that it was due to the SQL Entity Store trying to look up its own configuration in itself. Right?

For later readers; It is probably one of the trickiest bits of Qi4j, that Entity Stores are backing Configuration instances, which can be modified in runtime (and persisted), but many Entity Stores types need configuration. This is typically solved by placing additional entity stores (of a type that doesn't require configuration) either in a lower layer or in a separate module, where the entity store has Visibility.module.

Cheers

Niclas

--
You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

[Niclas Hedhman]

Also, looking at your example.

It is obvious that you want to get a feel for what Qi4j is. Let me point out that you (typically)  will use @UnitOfWorkPropagation to handle the unit of work creation, retries and completions.

You annotate the transaction boundaries (methods) with the above annotation with values describing what you need. Often we also put the above annotation on all domain layer methods, but of the Mandatory type, to check that something has set up a UnitOfWork, and not simply calling anyway, to catch bugs early.

You might also be interested in UoWFile library, which allows file system changes to be bound by UnitOfWork as well (although I think it is not crash recoverable yet. Paul?).

In general, in case you are not aware, we separate the indexing from the storage. And we allow multiple stores to co-exist for different purposes, maybe a combination of SQL, LDAP, Cassandra for customers, users and sensor data respectively. Setting that up requires a little bit of Architecture planning, you know, whiteboard and square boxes in layers ;-)  which is then set up in the application likewise.

Cheers

Niclas

[Paul Merlin]

Niclas Hedhman a écrit :

> You might also be interested in UoWFile library, which allows file
> system changes to be bound by UnitOfWork as well (although I think it
> is not crash recoverable yet. Paul?).

It should be pretty solid, even in case of JVM crash, as during a UoW
the original file remains untouched (copy/modify/move).

As stated in the UoWFile library documentation, note that it has a
performance impact relative to the files size as it duplicates the file
to keep a backup for eventual rollback. The API provides a way to get
non-managed handles on attached files to keep your read-only operations
fast.

/Paul

[Niclas Hedhman]

Ok, but what happens if the JVM is crashed during the 'move/delete' stage. My guess is that some files may contain changes, and others not. As the alternative is to copy the entire parent directory, modify and then rename the directory, plus the issue with concurrent access in this situation being a lot harder... Just asking... ;-)

--
You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.