Scaffolding as local as possible, without having to modify my original code
Added by Dave Far about 6 years ago
Hi,
since I want to keep my code for persistence as local as possible, I really like how wt::Dbo requires only a single template method to provide the mapping.
Is something similar possible for the scaffolding, i.e. to persist the (1to1- or 1toMany-) relationships my objects have with each other?
In detail: I already have the objects and their relationships written purely in C. Now I want to add the code for persistence as local as possible. This works great for mapping attributes using
template<class Action>
void persist(Action& a)
{ ...
}
However, using code like dbo::ptr<User> and dbo::collection< dbo::ptr<User> > throughout the objects I want to persist is not local at all, and I would have to modify the code I already have.
I am willing to write more verbose code (defining and using keys) as long as I only have to extend the code I already have, in a local way (i.e. neither modify it nor scatter the extensions all over the place). Is there some solution similar to the one above for mapping attributes? That would be totally awesome.
Replies (3)
RE: Scaffolding as local as possible, without having to modify my original code - Added by lm at about 6 years ago
to persist the (1to1- or 1toMany-) relationships my objects have with each other?
That's covered in detail at https://www.webtoolkit.eu/wt/doc/tutorial/dbo.html .
I already have the objects and their relationships written purely in C. Now I want to add the code for persistence as local as possible.
I assume the C you have describing the objects and their relationships is in a Wt::Dbo function template. If so, you don't need to add code for persistence. The persist function is code for persistence. I'm fairly convinced that I'm not understanding the question, though.
However, using code like dbo::ptr and dbo::collection< dbo::ptr > throughout the objects I want to persist is not local at all
I thought I knew what you were talking about by "local", but now I think I'm lost.
I would have to modify the code I already
Do you mean that you have some non-Wt::Dbo business objects that you're trying to put into your Wt application? It will be difficult to persist those non-Wt business objects with Wt::Dbo without changing them. As you point out, you'll at least need to implement the function template persist.
You can expect to have any code file that deals with business objects have to #include <Wt/Dbo/ptr.h>, etc. Is that what is bothering you?
Hopefully some of this is helpful? I'm happy to give more of what I know if I can be helpful.
RE: Scaffolding as local as possible, without having to modify my original code - Added by Dave Far about 6 years ago
Thanks for your reply.
Yes, I have some non-Wt::Dbo business objects that I now want to persist, using Wt::Dbo. I am fine with extending those classes by implementing the function template persist, but do not want to modify existing code of my classes. Is there an alternative to using dbo::ptr<User> and dbo::collection< dbo::ptr<User> >? Because that would require me to change the references and collections I am using right now in those classes. Maybe I can somehow also persist the scaffolding by only implementing some Wt::Dbo function template, as for the attribute mapping?
I hope I described my problem clearer now.
RE: Scaffolding as local as possible, without having to modify my original code - Added by lm at about 6 years ago
I'm afraid it won't be quite as easy as you hope. I think you will need to have local Wt::Dbo::collection fields to establish the one-to-many relationships. However, you don't really have to use them... In my code, any time I want a list of all the instances of a type, or all the related objects, I get a Wt::Dbo::collection, std::copy it to a std::vector then throw away the Wt::Dbo::collection. You can experiment with creating the Wt::Dbo::collection only in the persist function template, but I doubt that'll work...
Experimentation will guide you. It may be beneficial to create a smaller example; it takes more time up front, but 1) is easier to modify quickly and 2) clarifies the situation nicely.