2018 Feb 21 8:36 PM
Hello guys,
I'm searching for a best practice solution for accessing Z-Tables. My idea is to create an Interface for the CRUD operation, which can be used for all tables.
Maybe there is even a possibility to generate this class for new Z-Tables.
IF_DB_CRUD
create, update, delete, read
What about using "type ref to data" or "type data" as import/export structure?
And what about "mass" activities (deleting, creating several entries)?
Regards
Christopher
2018 Feb 21 9:25 PM
Ditto to Matthew’s answer. I have thought about it but don’t see much benefit. The added complication to make it generic negate the benefits - because now every developer is forced to use references or whatever. By hardcoding the IO parameters we make it easier for devs to just do a data(foo) = zcl_foo_db->read( ‘123’ ).
So explicit classes for me are a trade off in the developer’s favour. Persistent classes did a nice job of generating it for you, and I could also add object specific code in there, but they have sadly not kept up with the times.
Another idea is to go for BOPF. It’s a beastly framework but oh so versatile.
2018 Feb 21 8:45 PM
There was the persistence framework, but nowadays, I create a class for handling CRUD with the SQL in various methods. including those for mass operations.
2018 Feb 22 10:05 PM
I was just reading about this in the 2011 Thomas Jung's book "Next generation ABAP Development" (it was still too advanced for my old job in 7.01 version) and it seemed a bit heavy-handed to me. So are you saying we don't really need those persistent object classes anymore? Phew!
2018 Feb 23 6:18 AM
2018 Feb 23 11:41 AM
2018 Feb 23 12:18 PM
2018 Feb 23 2:26 PM
I too create custom global class to handle the SQL for my Z tables.
2018 Feb 21 9:25 PM
Ditto to Matthew’s answer. I have thought about it but don’t see much benefit. The added complication to make it generic negate the benefits - because now every developer is forced to use references or whatever. By hardcoding the IO parameters we make it easier for devs to just do a data(foo) = zcl_foo_db->read( ‘123’ ).
So explicit classes for me are a trade off in the developer’s favour. Persistent classes did a nice job of generating it for you, and I could also add object specific code in there, but they have sadly not kept up with the times.
Another idea is to go for BOPF. It’s a beastly framework but oh so versatile.
2018 Feb 22 5:29 PM
2018 Feb 22 6:53 PM
I mentioned it already somewhere else, but IMHO there is a need for a more lightweight solution compared to BOPF.
2018 Feb 22 5:30 PM
Hi,
If you want a good point of reference, take a look at report adbc_demo.
Update: Please see the comments for constraints and caveats.
2018 Feb 22 6:06 PM
2018 Feb 22 6:17 PM
I agree, looking at it is enough to spot the difference, but why it is not a point of reference for CRUD operations as the OP asked?
2018 Feb 22 8:58 PM
Cause I have written that example to demo some capabilities of ADBC (in fact there's the same for EXEC SQL), but not for CRUD.
2018 Feb 22 9:28 PM
I think you switched demo_amdp and adbc_demo.
I do agree that adbc_demo aim is to show the ABAP database call interface API and not for CRUD, but I found that the OO structure of it includes Creation of rows (method insert_rows), Reading of rows (methods select_into*), Updating of rows (method update_rows) and Deleting rows (method delete_rows), so that's why I pointed at it in this context.
Nonetheless, if you feel it is misleading or out of place, just say the word and I'll delete the answer and comments and deactivate my account 😉
2018 Feb 23 6:16 AM
Ah come on ...
If by chance the example hit something that can be called CRUD, so be it.
2018 Feb 23 7:31 AM
2018 Feb 23 7:37 AM
2018 Feb 22 9:59 PM
If this is "Christopher" then who is "Tanja Schipper"? I'm confused... Please be aware that profile sharing is frowned upon on SCN.