Auto increment service builder columns and modifying *Impl classes

[Chris Maggiulli, modificado 6 Anos atrás.]

I a multi part issue. I have searched the forums and extensively online and in the codebase. I have found no complete answer for either question regardless of what resource I use. I'm hoping someone on this forum can help me out.

Generally I create a surrogate in ServiceBuilder/Hibernate by using the primary attribute and then in my *LocalServiceImpl class I write the increment method myself with counterLocalService. That works. However, in an effort to minimize my code in favor of xml configuration I began looking at the servicebuilder dtd and saw that with hibernate / mysql its possible to have a self increment field in three different ways. Here is the way I decided on:

service.xml

<entity name="SerialNumber" local-service="true" remote-service="false">
<column name="id" type="int" primary="true" id-type="increment" />
<column name="name" type="String" />
<column name="desc" type="String" />

</entity>

ServiceBuilder runs fine and generates all the expected code. I have found several tutorials that bring me this far. However, absolutely none of them tell me how I call the create method in the *LocalServiceImpl class. The issue is that in the LocalServiceImpl class the create method still has the following signature:

createSerialNumber(long id);

I obviously could send in the increment again but that defeats the purpose. I have tried to ignore the create method and instead override the add method as follows

    public SerialNumber addSerialNumber(String name, String desc) throws SystemException {
	SerialNumber serialNumber = new SerialNumberImpl(name, location, description, enabled);
	
	return addRepository(serialNumber );
    }

This works and auto increments the field - however I see in the SerialNumberImpl class it says I should never reference directly. No tutorials go this far they just show you the xml parameters and end - they dont actually should how to create an entity in the serviceimpl. Basically I'm wondering if calling that *impl class is non optimal. And if so, is there any preferred way to build some type of factory?

[David H Nebinger, modificado 6 Anos atrás.]

Just use a zero (0) for the id when you call the createSerialNumber() method.

The underlying code will respect the isNew() value for the new entity and will increment or whatever.








Come meet me at the 2017 LSNA!

[Chris Maggiulli, modificado 6 Anos atrás.]

David H Nebinger:

Just use a zero (0) for the id when you call the createSerialNumber() method.

The underlying code will respect the isNew() value for the new entity and will increment or whatever.








Come meet me at the 2017 LSNA!

Thank you for the response. Just for my own knowledge - is referencing *impl classes in the way I posted originally wrong in all cases? Your solution worked fine and I have switched my code accordingly but I am still a bit interested in that class and its uses

[David H Nebinger, modificado 6 Anos atrás.]

Well, the verbiage is somewhat confusing...

All of your custom code should go into, for example, SerialNumberImpl (the model impl class), SerialNumberLocalServiceImpl (the local service impl), SerialNumberServiceImpl (the remote service impl). Your code goes there, but you never want to really reference it that way.

So, for example, although the SerialNumberLocalServiceBaseImpl has the createSerialNumber() method that effectively does a "new SerialNumberImpl();", you should not in your own code be referencing it that way. Doing so breaks a lot of the code Liferay may have in place to do different things that may or may not be documented.

Basically you are supposed to stick with agreed APIs to create new instances, set values, etc. so they put the message in there about not referencing directly.

So your addSerialNumber() method is actually wrong. Instead you want to do something like:

SerialNumber serialNumber = createSerialNumber(0);

serialNumber.setName(name);
serialNumber.setLocation(location);
serialNumber.setDescription(description);
serialNumber.setEnabled(enabled);

return addRepository(serialNumber );

So you avoid using any of the impl classes directly and instead rely on the provided APIs to do everything.







Come meet me at the 2017 LSNA!

[Chris Maggiulli, modificado 6 Anos atrás.]

Ok thanks for the reply

David H Nebinger:

Well, the verbiage is somewhat confusing...

All of your custom code should go into, for example, SerialNumberImpl (the model impl class), SerialNumberLocalServiceImpl (the local service impl), SerialNumberServiceImpl (the remote service impl). Your code goes there, but you never want to really reference it that way.

So, for example, although the SerialNumberLocalServiceBaseImpl has the createSerialNumber() method that effectively does a "new SerialNumberImpl();", you should not in your own code be referencing it that way. Doing so breaks a lot of the code Liferay may have in place to do different things that may or may not be documented.

Basically you are supposed to stick with agreed APIs to create new instances, set values, etc. so they put the message in there about not referencing directly.

So your addSerialNumber() method is actually wrong. Instead you want to do something like:

SerialNumber serialNumber = createSerialNumber(0);

serialNumber.setName(name);
serialNumber.setLocation(location);
serialNumber.setDescription(description);
serialNumber.setEnabled(enabled);

return addRepository(serialNumber );

So you avoid using any of the impl classes directly and instead rely on the provided APIs to do everything.







Come meet me at the 2017 LSNA!