[#1102] Implementation of the MORK type AdapterDB 2#1125
[#1102] Implementation of the MORK type AdapterDB 2#1125marcocapozzoli wants to merge 5 commits into
Conversation
…put and update constructor parameters
…ecute_task in MorkMappingStrategy
marcocapozzoli
changed the title
| LOG_DEBUG("Mapping MORK expression: " << expr); | ||
|
|
||
| vector<shared_ptr<Atom>> atoms; | ||
| std::queue<shared_ptr<Atom>>* batch_queue = new std::queue<shared_ptr<Atom>>(); |
There was a problem hiding this comment.
I didn't see where batch_queue is being deleted
| shared_ptr<BoundedSharedQueue> output_queue, | ||
| MAPPER_TYPE mapper_type) | ||
| : DatabaseWrapper(conn, MapperFactory::create(mapper_type)), | ||
| : DatabaseWrapper(*conn, MapperFactory::create(mapper_type)), |
There was a problem hiding this comment.
This very error prone. Inside DatabaseWrapper you are storing a reference to an object attached to a shared_ptr. but this reference is not known by the shared_ptr which means that when the count in shared_ptr reaches ZERO (i.e. when all the shared_ptr which have copied the same obj is deleted) the object itself is deleted turning the reference inside DatabaseWrapper bogus.
I suggest passing (and storing inside DatabaseWrapper the shared_ptr itself instead of a reference to the object.
| MAPPER_TYPE mapper_type) | ||
| : DatabaseWrapper(conn, MapperFactory::create(mapper_type)), | ||
| : DatabaseWrapper(*conn, MapperFactory::create(mapper_type)), | ||
| conn(conn), |
There was a problem hiding this comment.
This is even weirder. The superclass already store a connection object. And here you have the subclass storing it again. This is a design flaw.
| private: | ||
| mutex api_mutex; | ||
| MorkConnection& conn; | ||
| shared_ptr<MorkConnection> conn; |
There was a problem hiding this comment.
See comment above. The superclass already has an object of this type.
2 participants
Uh oh!
There was an error while loading. Please reload this page.