Service builder does not update db.

[Peter Hellstrand, módosítva 12 év-val korábban]

Hi

I am using the service builder. When I run build-service command and restart the server no updates are present in my db.

1. I create an empty db.
2. I run " build-service" and start the server. Tables are created.
3. I import a db dump that removes some of my columns. This is correct.
4. I run "build-service" and restart tomcat. I don't get any updates om my tables.

Shouldn't my tables get updated to match service.xml data model?

Thanks.

[Pankaj Kathiriya, módosítva 12 év-val korábban]

Hi Peter,

Are you deploying component after running build-service??
db changes are done when you deploy your component.

HTH,
Thanks,
Pankaj

[Peter Hellstrand, módosítva 12 év-val korábban]

Hi Pankaj,

Yes I am deploying after build-service.

[David H Nebinger, módosítva 12 év-val korábban]

Peter Hellstrand:

Shouldn't my tables get updated to match service.xml data model?

Nope. The SB code will invoke the create script when the table(s) do not exist, but will not update them for you.

Liferay gets around this by keeping track of the db version. At startup, Liferay checks it's version against the version in the database; if they match, fine, if not the appropriate update scripts are run and the db version is updated to the Liferay version.

Just doing updates to the service.xml does not leave enough information around for Liferay to automagically update your tables; you must build your own logic to make that happen.

[Peter Hellstrand, módosítva 12 év-val korábban]

Ok. I did not expect that.

Thank you.

[Chiara Crovetto, módosítva 10 év-val korábban]

David H Nebinger:

Just doing updates to the service.xml does not leave enough information around for Liferay to automagically update your tables; you must build your own logic to make that happen.

Hello, I do not understand since "sometimes" it does update the db. It has even deleted some entries that had columns with too many characters to fit the new table declaration.
So... I saw that could be a little bug of my version of Liferay (6.1) that compares badly build numbers of services... But how can I fix this? The fact that "sometimes" it deletes db entries is absolutely not good.

The second problem is that the file service-ext.properties is not read since (maybe) in this line of service.properties

include-and-override=${base.path}/service-ext.properties

there is a property base.path that is not set anywhere (or not?)

Does have anybody found a solution for these problems?

[David H Nebinger, módosítva 10 év-val korábban]

Chiara Crovetto:

Hello, I do not understand since "sometimes" it does update the db. It has even deleted some entries that had columns with too many characters to fit the new table declaration.
So... I saw that could be a little bug of my version of Liferay (6.1) that compares badly build numbers of services... But how can I fix this? The fact that "sometimes" it deletes db entries is absolutely not good.

Always manage your own updates (all of them). To do this you create a Release entity for your service and track the version there. You also include a startup action where you check the version of the Release against what you are deploying; if they're the same value, you're done.

If the values differ, you apply appropriate DDL to make the database compatible with your service. Liferay will do this by having all DDL and do the individual updates to get up to the current version (i.e. if Release is 4 and you have 7, you would apply DDL to update to 5, then to 6, and finally to 7).

The second problem is that the file service-ext.properties is not read since (maybe) in this line of service.properties

include-and-override=${base.path}/service-ext.properties

there is a property base.path that is not set anywhere (or not?)

Base path is managed by Liferay and will resolve to your war's WEB-INF/classes directory.

[Chiara Crovetto, módosítva 10 év-val korábban]

Ok, I agree that is better to manage updates by my own but the property
build.auto.upgrade=false
that we can set in service-ext.properties is not always read by the portal that tries to update the db by himself...
My Liferay version is 6.1.1

[David H Nebinger, módosítva 10 év-val korábban]

It is always read but not always clear that an 'upgrade' is called for.

End of the day, you should be managing your own updates and not rely on what SB may or may not do for you.

[Chiara Crovetto, módosítva 10 év-val korábban]

The upgrade is called also if I set build.auto.upgrade=false ?
Are you saying that I should stop using service builder? Because if not there will always be something trying to update db

[David H Nebinger, módosítva 10 év-val korábban]

No, I'm not saying "don't use service builder".

Service builder is the best tool for providing access to your data entities across many separate portlets. It is an integral part of Liferay and the Liferay sphere and is honestly the best tool for the job.

But SB is not perfect. You should not use SB to manage your database update code. You should do this yourself through a combination of Release record entry and a startup action.

As I read through your question, I'm wondering if you're confusing updating records in the database /w updating the DDL, the table definitions themselves. This thread was started to cover issues in attempting to update the table structures (columns, types, etc) and was not about updating records in the database...

[Christophe Noel, módosítva 9 év-val korábban]

Hello,

It seems that the UpgradingProcess you're talking about is explained here :
https://www.liferay.com/web/ryan.park/blog/-/blogs/implementing-upgradingprocess-for-your-liferay-portlets!

Can this tutorial be applied to the service.properties instead of the portal.properties ?
Does the release.info.build.number is independant/distinct of the build.number in service.properties ?

Thanks for your help.

[David H Nebinger, módosítva 9 év-val korábban]

They really should be considered separately...

Service API changes do not have to occur for a new release of your plugin. Once you set your service API, the only time you have to change it is if a DB change is necessary. You don't have to rebuild services if you change the implementation code (as long as you don't change method signatures).

Your plugin, however, can go through additional releases that add functionality (visually or something) or fix bugs that would not necessarily have any dependency on service version changes.

[Christophe Noel, módosítva 9 év-val korábban]

Ok thanks, therefore, I'm not sure to understand what you're talking about when you advise for:

Always manage your own updates (all of them). To do this you create a Release entity for your service and track the version there.

What do you mean by create a Release entity for table updates if you're not talking about this ?

Thanks.

[David H Nebinger, módosítva 9 év-val korábban]

Release is yet another entity type (like a blog entry or a user or ...).

You can use ReleaseLocalServiceUtil to add a release, update a release, get a release, ... So you use a startup action for your portlet and, when your method is called, you have 4 possible paths to deal with:

1. No existing release record - this is your first deployment, you can do whatever extra work is necessary but know that SB will create your initial tables, but you could do that anyway here. Last step is to add a new release record for future tracking.

2. Existing release record that matches current value - this is just a startup, no change necessary.

3. Existing record but older version - this is your upgrade path, this is where you can take whatever actions are necessary. Remember to update your release record.

4. Existing record but newer version - admin has tried to deploy an older version of your plugin. You should figure out what you can do here, whether you can actually run (probably not likely because of SB table changes) or not, but you do need to take some sort of action here.

[Christophe Noel, módosítva 9 év-val korábban]

Thanks, David. Very interesting. Any documentation available on that topic (except sources maybe) ? I have never read this before.

Regards,
Christophe.

[David H Nebinger, módosítva 9 év-val korábban]

No, like many other features of Liferay, this one is undocumented.

I've taken to using it for everything I'm building so I can track things like versions, cluster deployment issues, etc.

[Fuad Efendi, módosítva 7 év-val korábban]

UPDATE for Liferay 7, 2016.09.07:
Creating an Upgrade Process for your App

For example, I blindly copy-pasted following into my bnd.bnd after which automatic upgrade stopped working:
Liferay-Require-SchemaVersion: 1.0.0

Fortunately I found above-mentioned documentation:

If your database schema is a different version than your module version, you can specify it in the BND file. Add the Require-SchemaVersion property to your bnd.bnd file to describe that the schema version of the module uses a different version than the bundle version

In most simple cases no any upgrade process needed; Liferay relies on generated by service builder timestamp and release numbers in "service.properties":

    build.namespace=FE
    build.number=123
    build.date=1473279898498
    build.auto.upgrade=true

You will need explicit upgrade process only if you risk to lose data. For example, if you already have this Service deployed in production, and you need to migrate to new version.

P.S.
https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/configuring-service-properties

The build.auto.upgrade property is available for WAR-style Service Builder applications. This property determines whether or not Liferay should automatically apply changes to the database model when a new version of the plugin is deployed. This is true by default. This property is not necessary for module-style applications.