Move the Comment class to the new backend interface#2225
Conversation
muhrin
left a comment
There was a problem hiding this comment.
Do we have any tests? It looks like your Comment class was abstract but this doesn't seem to have been caught. Maybe everywhere in the code is still uses backend.comments....if so these should be changed to Comment.
There was a problem hiding this comment.
| @abc.abstractproperty |
There was a problem hiding this comment.
| pass | |
| return self._backend_entity.uuid |
There was a problem hiding this comment.
| pass | |
| return self._backend_entity.get_ctime() |
There was a problem hiding this comment.
| pass | |
| return users.User.from_backend_entity(self._backend_entity.get_user()) |
There was a problem hiding this comment.
| pass | |
| self._backend_entity.set_user(value.backend_entity) |
There was a problem hiding this comment.
See comment above about ctime
|
The only "tests" that were in place are indirect through the |
|
Quick comment - I was just wondering if we need an entity also for comments (and similarly for links) or these can just be considered as a "property" of Node (even if in our implementation they live in a different DB table). Because then intuitively if it's an entity one would expect to be able to "join" them via the query builder. Of course since this implemented it's fine to keep as it is, I point out this just for discussion and to decide what to do with the other tables that do not have a corresponding entity (notably links but maybe something else?) |
|
Good point @giovannipizzi , so long as the interface is clear (i.e. the comment interaction is properly defined through the |
|
At the current stage having it as a separate full-fledged entity seems a bit overkill, agree, but I can easily imagine that when we do start to use it, it will be very useful to have it queryable. As I understand its original intention, it is for users to comment on certain nodes, i.e. in a discussion on a platform like MaterialsCloud or just when sharing nodes. For this use case, being able to find all nodes on which a particular user has commented, would be useful. Should we leave it like this for now and I just add tests for the ORM classes? |
|
Yes, leave it as is. Some testing is good but for now I reckon a 'system testing' approach is fine i.e. just rely on higher level functions like the verdi command line tests to put it through its paces. |
|
Ok for me. rather even if maybe it makes the QB code more complex. I'm open to suggestions. |
ea4cc22 to
10eda70
Compare
|
I added support for querying |
7e9c96e to
64ad5e1
Compare
There was a problem hiding this comment.
This is not needed. The ModelWrapper does this for all attributes anyway. Sorry I missed it the first time.
There was a problem hiding this comment.
| raise exceptions.ModificationNotAllowed | |
| raise exceptions.ModificationNotAllowed('The corresponding node and/or user are not stored') |
There was a problem hiding this comment.
| raise exceptions.ModificationNotAllowed | |
| raise exceptions.ModificationNotAllowed('The corresponding node and/or user are not stored') |
There was a problem hiding this comment.
| comments.__all__ + |
64ad5e1 to
ff09cde
Compare
This allows to make the methods of `Node` backend independent and as a result makes the implementation a lot simpler. The command line interface is also adapted and simplified.
ff09cde to
f5406dd
Compare
Fixes #2223