12:28 a.m.
I have converted everything in the JpaHibernateContentPersistenceService class to use JPA
native queries save the table creation and the ListRequest stuff, but that's easy. The
table creation is a bit of a problem, because you're not supposed to be doing DDL via
JPA. Are these tables actual tables we don't know anything about a deploy time?
What's the reason for creating them at runtime?
If we need to create them at runtime then I'm going to have to switch over to
injecting the DataSource (which is how it probably should have been done in the first
place if you're going to use JDBC) and grabbing a connection that way then doing all
the JDBC stuff as normal (try with resources would be helpful here but we're using
Java 6. If OpenShift supports Java 7 how about we upgrade?). The problem standing in my
way with doing that is that we don't have a common name for the datasource. My
suggestion is to create a searchisko-ds.xml file to deploy, standardize the name
(SearchiskoDS seems good) and then have maven make the changes to the searchisko-ds.xml
file depending on the profile.
Thoughts?
4:11 a.m.
Hi Jason,
regarding dynamic creation of tables.
Content persistence service creates separate table for each type of
content stored in Searchisko which is also marked to be persisted there.
Content types are configured dynamically in Searchisko, so we need
dynamic table creation.
Second option I thought about was to store all document types into one
table and only use column to distinguish type.
But this may lead to really huge table with miriads of rows, which will
be hard/slow to use and maintain. So I decided to use the multi table
approach there.
I don't think it is good solution to cripple design due limitations of
some technology (JPA in this case).
Regarding rewriting JDBC stuff to use injected DataSource I have no
problem with this. Only be carefull to patch configurations for
OpenShift too to provide MySQL DS under name you expect.
Cheers
Vlastimil
On 3.10.2013 07:28, Jason Porter wrote:
I have converted everything in the
JpaHibernateContentPersistenceService class to use JPA native queries save the table
creation and the ListRequest stuff, but that's easy. The table creation is a bit of a
problem, because you're not supposed to be doing DDL via JPA. Are these tables actual
tables we don't know anything about a deploy time? What's the reason for creating
them at runtime?
If we need to create them at runtime then I'm going to have to switch over to
injecting the DataSource (which is how it probably should have been done in the first
place if you're going to use JDBC) and grabbing a connection that way then doing all
the JDBC stuff as normal (try with resources would be helpful here but we're using
Java 6. If OpenShift supports Java 7 how about we upgrade?). The problem standing in my
way with doing that is that we don't have a common name for the datasource. My
suggestion is to create a searchisko-ds.xml file to deploy, standardize the name
(SearchiskoDS seems good) and then have maven make the changes to the searchisko-ds.xml
file depending on the profile.
Thoughts?
_______________________________________________
searchisko-dev mailing list
searchisko-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/searchisko-dev
--
Vlastimil Elias
Senior Software Engineer
jboss.org Development Team
4102
days inactive
4102
days old
searchisko-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Jason Porter -
Vlastimil Elias