Message Boards

External Tables and Liferay advanced functions

thumbnail
Andre Kreienbring, modified 3 Years ago.

External Tables and Liferay advanced functions

Regular Member Posts: 152 Join Date: 12/18/06 Recent Posts
I'm using Service Builder with tables / entities from a external DB.
I was able to implement the management toolbar, the searchcontainer a displaycontext etc.
Now I wonder if functions like search, audits and workflow can be implemented with an external DB.
I believe there must be certain fields / columns present on the entities, like groupId, companyId and so forth.  And apparently also finders. But if they are present, would I be able to use these Liferay specific features with an external DB?
thumbnail
David H Nebinger, modified 3 Years ago.

RE: External Tables and Liferay advanced functions

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
The fact that a table is from an external database or not doesn't matter at all.

If you build your entities using ServiceBuilder, all features of Liferay become available to you if you just add the extra pieces. Workflow, asset framework, search and indexing, trashcan support, auditing, etc are all based upon ServiceBuilder, which doesn't care if the table is actually in an external database.
thumbnail
Andre Kreienbring, modified 3 Years ago.

RE: External Tables and Liferay advanced functions

Regular Member Posts: 152 Join Date: 12/18/06 Recent Posts
Ok, so it's worth to give it a try and I'm on my way implementing search and indexing.
First thing I already noticed is, that this old thread complaining that "getIndexableActionableDynamicQuery()" is not created, hits me as well. This method seems to be necessary to get the indexing working...
Now I'll change all my primary keys to the type long, to see if that is the reason...
Stay tuned folks! ;-)
thumbnail
Andre Kreienbring, modified 3 Years ago.

RE: External Tables and Liferay advanced functions

Regular Member Posts: 152 Join Date: 12/18/06 Recent Posts
True, the IndexableActionableDynamicQuery method in a [Your Entitiy]LocalServiceBaseImpl is only created if the type of the primary key in that entity is "long".
Also, if you look at the code of that method:
    @Override
    public IndexableActionableDynamicQuery
        getIndexableActionableDynamicQuery() {
        IndexableActionableDynamicQuery indexableActionableDynamicQuery =
            new IndexableActionableDynamicQuery();
        indexableActionableDynamicQuery.setBaseLocalService(
            deviceBindingLocalService);
        indexableActionableDynamicQuery.setClassLoader(getClassLoader());
        indexableActionableDynamicQuery.setModelClass(DeviceBinding.class);
        indexableActionableDynamicQuery.setPrimaryKeyPropertyName("autoId");
        return indexableActionableDynamicQuery;
    }
there can only be one property set as the primary key. So that excludes tables with composite primary keys from indexing.
I've also noticed that Liferay Service Builer requires one primary key to be present in every  entity.
Together with the necessary fields for workflow status, site management and audits that gives a clear picture of how to design a DB, if you want to integrate it with the powerful Liferay features. :-)
thumbnail
David H Nebinger, modified 3 Years ago.

RE: External Tables and Liferay advanced functions

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Putting Liferay aside for a moment...

Natural keys and compound keys are typically bad design choices. Often times it seems as though selecting a natural key is of course the right thing to do, but eventually you will hit upon a case where you become stuck because the natural key really isn't completely natural (i.e. you choose email address as a key because of course a user might have only one account which works until the day that, for some reason the business supports, a single user might want/need multiple accounts, but your natural key choice now prevents this kind of thing from happening).

Compound keys are even worse because you often want to do partial key lookups/groups/etc, so it is less of a key and more of a categorization.

A surrogate key is the answer to both of these problems. Surrogate keys do not suffer from business rule changes or anything because they have no business meaning, yet they still provide a unique value to easily select a specific row.

And now back to Liferay, Liferay encourages the use of surrogate keys and, while natural and compound keys are options for general table matching, they are impossible for Liferay to use with many of the Liferay frameworks. For example, in the Asset framework, everything is an asset but this relationship is maintained using an entity class name and primary (surrogate) key value which is a long. There's no other mechanism to support non-long keys and especially not compound keys with multiple unknown column types.

So yes, you are forced to use a long surrogate key for your tables, but these have additional benefits as shown above that support that restriction.
thumbnail
Andre Kreienbring, modified 3 Years ago.

RE: External Tables and Liferay advanced functions

Regular Member Posts: 152 Join Date: 12/18/06 Recent Posts
True, and an additional hint for those who use natural and / or composite primary keys to prevent duplicate entries in a table (like I did):  Switch to UNIQUE Indexes.