Aritz Galdos 3 Years Ago - Edited Come on! As Liferay was a bug-free product! I could understand if you say.. "do it at your own risk" or whatever... but as an user of Liferay CE since Liferay 4.2 I had to dive into de DB sooo many times to solve bugs (Malfunction, stuck upgrade processes ... ). And that's OK!! And if you change something you are on your own. I have learnt a lot diving into DB and I would suggest just the opposite to "Never look inside the Liferay database". Always look into DB!! YO will learn a lot. I thint that's not the way to build and challenge a community at all. An open source community. At least in this article you don't say "our db is not ours" Please sign in to reply. Reply as... Cancel David H Nebinger Aritz Galdos 3 Years Ago - Edited Hi, Aritz. When I post these blogs, they're not really for you, my friend. After working with Liferay for so long I'm sure you recognize the patterns, can predict where something is going sideways and yes, have gone into the database successfully and made changes. I don't begrudge you that level of detail because I know that with so much experience, you understand the implications of everything you are about to do. I do write the blogs though for new people coming to the platform, the ones without the experience of you or I. To those that don't know the implications that can come from adding a column to a Liferay table or deleting rows directly w/o updating the index or even changing data without knowing how Liferay handles code-enforced row relationships. For those folks, they really can get themselves in trouble. Like the poster of the message I was writing about, his team is in a real pickle now with no simple way to move forward. At the time when they started the project, had they followed these two rules, they wouldn't be in the shape they are now. That's who this blog is for, the ones that don't know what they don't know, the ones that need some guide rails otherwise they could drive themselves off the edge of the road. Please sign in to reply. Reply as... Cancel Aritz Galdos David H Nebinger 3 Years Ago - Edited Well. Then I agree. :) Thanks David Please sign in to reply. Reply as... Cancel Christopher Kaag Aritz Galdos 3 Years Ago - Edited I agree, looking into the database will help a lot, especially when dealing with newer features. It's okay to look into the database and make assumptions based on what you learned. But always find a way to verify those assumptions both now and in future versions. E.g., run some smoke tests after a database upgrade for every little thing of yours that needs knowledge of the database. If you have no way of continously checking your assumptions, they're worth nothing. Please sign in to reply. Reply as... Cancel
David H Nebinger Aritz Galdos 3 Years Ago - Edited Hi, Aritz. When I post these blogs, they're not really for you, my friend. After working with Liferay for so long I'm sure you recognize the patterns, can predict where something is going sideways and yes, have gone into the database successfully and made changes. I don't begrudge you that level of detail because I know that with so much experience, you understand the implications of everything you are about to do. I do write the blogs though for new people coming to the platform, the ones without the experience of you or I. To those that don't know the implications that can come from adding a column to a Liferay table or deleting rows directly w/o updating the index or even changing data without knowing how Liferay handles code-enforced row relationships. For those folks, they really can get themselves in trouble. Like the poster of the message I was writing about, his team is in a real pickle now with no simple way to move forward. At the time when they started the project, had they followed these two rules, they wouldn't be in the shape they are now. That's who this blog is for, the ones that don't know what they don't know, the ones that need some guide rails otherwise they could drive themselves off the edge of the road. Please sign in to reply. Reply as... Cancel Aritz Galdos David H Nebinger 3 Years Ago - Edited Well. Then I agree. :) Thanks David Please sign in to reply. Reply as... Cancel
Aritz Galdos David H Nebinger 3 Years Ago - Edited Well. Then I agree. :) Thanks David Please sign in to reply. Reply as... Cancel
Christopher Kaag Aritz Galdos 3 Years Ago - Edited I agree, looking into the database will help a lot, especially when dealing with newer features. It's okay to look into the database and make assumptions based on what you learned. But always find a way to verify those assumptions both now and in future versions. E.g., run some smoke tests after a database upgrade for every little thing of yours that needs knowledge of the database. If you have no way of continously checking your assumptions, they're worth nothing. Please sign in to reply. Reply as... Cancel
Alberto Chaparro 3 Years Ago Thanks David, that's the correct approach. Please sign in to reply. Reply as... Cancel
Jonas Choi 3 Years Ago I will add that many years ago, when I was in Support, I helped a customer with an upgrade that was failing? The reason? They had added custom columns into an existing Liferay table. The upgrade worked fine once the tables were removed, so the best way for them moving forward would be to use Custom Fields or Service Builder. Please sign in to reply. Reply as... Cancel