Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Brainstorm
  4. Implementing many-to-many relationships

Implementing many-to-many relationships

Scheduled Pinned Locked Moved Solved Brainstorm
40 Posts 8 Posters 10.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • mzimmersM Offline
    mzimmersM Offline
    mzimmers
    wrote on last edited by
    #1

    Hi all -

    Not really a Qt question, but...I'm working on an app that several object classes, such as:

    • location
    • equipment
    • activity
    • probably a couple others

    There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices:

    1. Each object will maintain a list of associated items: for example, a location object will have lists that point to equipment object identifiers, activity object identifiers, etc. and so on. Other objects would have similar lists. This approach will have some redundancy, but it won't be terrible, as an installation will likely have fewer than 100 instances of any class. Updating the relationship, of course, will have to be done in two places, and while again the overhead won't be bad, there's greater risk of "missing something."

    2. maintain a few separate lists that enumerate the relationships. This approach would simplify the contents of the classes I mentioned, but at the expense of creating a new class (the list itself).

    There are doubtless other approaches, but these are the 2 that come to mind. Currently, I'm leaning towards the latter.

    I'm not looking for a definitive answer (just thinking out loud), but...what does anyone think about the respective merits of either approach?

    Thanks for any ideas...

    T JonBJ kshegunovK 3 Replies Last reply
    0
    • mzimmersM mzimmers

      Hi all -

      Not really a Qt question, but...I'm working on an app that several object classes, such as:

      • location
      • equipment
      • activity
      • probably a couple others

      There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices:

      1. Each object will maintain a list of associated items: for example, a location object will have lists that point to equipment object identifiers, activity object identifiers, etc. and so on. Other objects would have similar lists. This approach will have some redundancy, but it won't be terrible, as an installation will likely have fewer than 100 instances of any class. Updating the relationship, of course, will have to be done in two places, and while again the overhead won't be bad, there's greater risk of "missing something."

      2. maintain a few separate lists that enumerate the relationships. This approach would simplify the contents of the classes I mentioned, but at the expense of creating a new class (the list itself).

      There are doubtless other approaches, but these are the 2 that come to mind. Currently, I'm leaning towards the latter.

      I'm not looking for a definitive answer (just thinking out loud), but...what does anyone think about the respective merits of either approach?

      Thanks for any ideas...

      T Offline
      T Offline
      tilz0R
      wrote on last edited by
      #2

      @mzimmers think how you would do it in the SQL relation. A table in between, that could be in C++ implemented as an array of classes with pointers to your objects.

      mzimmersM 1 Reply Last reply
      1
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote on last edited by
        #3

        Hi,

        Simpler is cleaner, go with the latter !

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        1
        • T tilz0R

          @mzimmers think how you would do it in the SQL relation. A table in between, that could be in C++ implemented as an array of classes with pointers to your objects.

          mzimmersM Offline
          mzimmersM Offline
          mzimmers
          wrote on last edited by
          #4

          @tilz0R an intermediate table is probably the better choice. I don't think, though, that I want to use pointers. I think it would be getter to give each item a unique identifier, and use that identifier in the table. Given how small my lists will be, there's really not much overhead searching through them for the desired items.

          SGaistS 1 Reply Last reply
          0
          • mzimmersM mzimmers

            @tilz0R an intermediate table is probably the better choice. I don't think, though, that I want to use pointers. I think it would be getter to give each item a unique identifier, and use that identifier in the table. Given how small my lists will be, there's really not much overhead searching through them for the desired items.

            SGaistS Offline
            SGaistS Offline
            SGaist
            Lifetime Qt Champion
            wrote on last edited by
            #5

            @mzimmers maybe a QMultiHash would be an idea.

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            mzimmersM 1 Reply Last reply
            1
            • SGaistS SGaist

              @mzimmers maybe a QMultiHash would be an idea.

              mzimmersM Offline
              mzimmersM Offline
              mzimmers
              wrote on last edited by
              #6

              @SGaist what would be the benefit of a multihash over a plain hash? I'd expect my keys would be unique.

              Otherwise, it sounds like a good idea.

              SGaistS 1 Reply Last reply
              0
              • mzimmersM mzimmers

                @SGaist what would be the benefit of a multihash over a plain hash? I'd expect my keys would be unique.

                Otherwise, it sounds like a good idea.

                SGaistS Offline
                SGaistS Offline
                SGaist
                Lifetime Qt Champion
                wrote on last edited by
                #7

                @mzimmers the multi hash has several values for one key so you have the one to many part with it.

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                mzimmersM 1 Reply Last reply
                1
                • SGaistS SGaist

                  @mzimmers the multi hash has several values for one key so you have the one to many part with it.

                  mzimmersM Offline
                  mzimmersM Offline
                  mzimmers
                  wrote on last edited by
                  #8

                  @SGaist ohhhh, NOW I get your point. Yes, that probably is a better way to do it. And, if the backend should prove not to contain multihash support, it should be a straightforward matter to convert.

                  Great idea...thanks.

                  mzimmersM 1 Reply Last reply
                  0
                  • mzimmersM mzimmers

                    @SGaist ohhhh, NOW I get your point. Yes, that probably is a better way to do it. And, if the backend should prove not to contain multihash support, it should be a straightforward matter to convert.

                    Great idea...thanks.

                    mzimmersM Offline
                    mzimmersM Offline
                    mzimmers
                    wrote on last edited by
                    #9

                    So, to further this a bit, let's say I create a table that contains all the associations between activities and equipment. When I create my activity and equipment objects (which contain lists themselves), I'll pass them a pointer to this table. My activity and equipment objects must contain functions to retrieve information on a list entry based on the UUID value retrieved from the table.

                    Of course, this means that each class (Activity, Equipment, etc.) must have knowledge of the other classes, in order to access those retrieval functions. This could make for some cruddy code.

                    I realize that such an approach could get unwieldy if I had many such classes and relationships, but in this application it's only going to be a handful. Does this seem like a reasonable way to go? Is there a preferred method of doing this?

                    Thanks...

                    1 Reply Last reply
                    0
                    • SGaistS Offline
                      SGaistS Offline
                      SGaist
                      Lifetime Qt Champion
                      wrote on last edited by
                      #10

                      Do these object have a common interface ?
                      Are they QObject based ?

                      Interested in AI ? www.idiap.ch
                      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                      mzimmersM 1 Reply Last reply
                      0
                      • SGaistS SGaist

                        Do these object have a common interface ?
                        Are they QObject based ?

                        mzimmersM Offline
                        mzimmersM Offline
                        mzimmers
                        wrote on last edited by
                        #11

                        @SGaist said in Implementing many-to-many relationships:

                        Do these object have a common interface ?

                        Not sure what you mean by this.

                        Are they QObject based ?

                        The lists are, but the items contained by a list are not (because basing them off of QObject would lose the copy c'tor and the assignment operator, and I need to copy these [I think]).

                        Kent-DorfmanK 1 Reply Last reply
                        0
                        • mzimmersM mzimmers

                          @SGaist said in Implementing many-to-many relationships:

                          Do these object have a common interface ?

                          Not sure what you mean by this.

                          Are they QObject based ?

                          The lists are, but the items contained by a list are not (because basing them off of QObject would lose the copy c'tor and the assignment operator, and I need to copy these [I think]).

                          Kent-DorfmanK Offline
                          Kent-DorfmanK Offline
                          Kent-Dorfman
                          wrote on last edited by
                          #12

                          @mzimmers said in Implementing many-to-many relationships:

                          @SGaist said in Implementing many-to-many relationships:

                          Do these object have a common interface ?

                          Not sure what you mean by this.

                          I think what he is asking is whether you can create a common abstract or pure virtual class that defines a common set of actions shared by the various concrete object...or multiple interface bases.

                          mzimmersM 1 Reply Last reply
                          0
                          • Kent-DorfmanK Kent-Dorfman

                            @mzimmers said in Implementing many-to-many relationships:

                            @SGaist said in Implementing many-to-many relationships:

                            Do these object have a common interface ?

                            Not sure what you mean by this.

                            I think what he is asking is whether you can create a common abstract or pure virtual class that defines a common set of actions shared by the various concrete object...or multiple interface bases.

                            mzimmersM Offline
                            mzimmersM Offline
                            mzimmers
                            wrote on last edited by
                            #13

                            @Kent-Dorfman said in Implementing many-to-many relationships:

                            I think what he is asking is whether you can create a common abstract or pure virtual class that defines a common set of actions shared by the various concrete object...or multiple interface bases.

                            So, base my various list classes from a common class? I could certainly do that. I'm not sure how this is going to move the needle, though.

                            1 Reply Last reply
                            0
                            • mzimmersM mzimmers

                              Hi all -

                              Not really a Qt question, but...I'm working on an app that several object classes, such as:

                              • location
                              • equipment
                              • activity
                              • probably a couple others

                              There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices:

                              1. Each object will maintain a list of associated items: for example, a location object will have lists that point to equipment object identifiers, activity object identifiers, etc. and so on. Other objects would have similar lists. This approach will have some redundancy, but it won't be terrible, as an installation will likely have fewer than 100 instances of any class. Updating the relationship, of course, will have to be done in two places, and while again the overhead won't be bad, there's greater risk of "missing something."

                              2. maintain a few separate lists that enumerate the relationships. This approach would simplify the contents of the classes I mentioned, but at the expense of creating a new class (the list itself).

                              There are doubtless other approaches, but these are the 2 that come to mind. Currently, I'm leaning towards the latter.

                              I'm not looking for a definitive answer (just thinking out loud), but...what does anyone think about the respective merits of either approach?

                              Thanks for any ideas...

                              JonBJ Online
                              JonBJ Online
                              JonB
                              wrote on last edited by
                              #14

                              @mzimmers
                              Since this is "Brainstorm" I can just make an unhelpful observation, right? Everyone here says do the relationships with external maps/tables. This is indeed how relational databases do it, but it seems to me that's completely non-OO, which is a shame in your C++ code. Objects having their own lists of other related objects may be "trickier" to ensure code gets it right but to me fits more neatly into a nice OO paradigm.

                              Just saying :)

                              1 Reply Last reply
                              0
                              • mzimmersM mzimmers

                                Hi all -

                                Not really a Qt question, but...I'm working on an app that several object classes, such as:

                                • location
                                • equipment
                                • activity
                                • probably a couple others

                                There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices:

                                1. Each object will maintain a list of associated items: for example, a location object will have lists that point to equipment object identifiers, activity object identifiers, etc. and so on. Other objects would have similar lists. This approach will have some redundancy, but it won't be terrible, as an installation will likely have fewer than 100 instances of any class. Updating the relationship, of course, will have to be done in two places, and while again the overhead won't be bad, there's greater risk of "missing something."

                                2. maintain a few separate lists that enumerate the relationships. This approach would simplify the contents of the classes I mentioned, but at the expense of creating a new class (the list itself).

                                There are doubtless other approaches, but these are the 2 that come to mind. Currently, I'm leaning towards the latter.

                                I'm not looking for a definitive answer (just thinking out loud), but...what does anyone think about the respective merits of either approach?

                                Thanks for any ideas...

                                kshegunovK Offline
                                kshegunovK Offline
                                kshegunov
                                Moderators
                                wrote on last edited by
                                #15

                                @mzimmers said in Implementing many-to-many relationships:

                                There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices

                                You're asking it backwards. Before deciding the choices, you have to actually clarify what sort of relationships we are talking about. The chosen word is a bad one, as it's a catch all for many different things. Is there hierarchical structure to them, or not (this'd imply ownership)? Perhaps those objects are peers, or composed in some other way? From the names I'd say it's a mixture of owning and peer-like relationships, or perhaps some objects are self-owning?
                                More info needed.

                                Read and abide by the Qt Code of Conduct

                                mzimmersM 1 Reply Last reply
                                1
                                • kshegunovK kshegunov

                                  @mzimmers said in Implementing many-to-many relationships:

                                  There will be multiple instances of each class, and a many-to-many relationship between them. I'm trying to decide how best to implement these relationships. There seems to be two basic choices

                                  You're asking it backwards. Before deciding the choices, you have to actually clarify what sort of relationships we are talking about. The chosen word is a bad one, as it's a catch all for many different things. Is there hierarchical structure to them, or not (this'd imply ownership)? Perhaps those objects are peers, or composed in some other way? From the names I'd say it's a mixture of owning and peer-like relationships, or perhaps some objects are self-owning?
                                  More info needed.

                                  mzimmersM Offline
                                  mzimmersM Offline
                                  mzimmers
                                  wrote on last edited by
                                  #16

                                  @kshegunov maybe this will help describe what I'm trying to do:

                                  The controller (the hardware that hosts the application) supports a site. Within a site, there may be one or more zones (referred to as "locations" above), equipment items, and activities.

                                  One zone may use several equipment items and several activities. A given piece of equipment may support multiple zones and activities. And an activity may entail multiple zones.

                                  Based on the preceding, I don't think there is any "ownership" in the UML sense of the word.

                                  @JonB your suggestion was my original idea. But, you're right about the potential trickiness of implementation. As @SGaist pointed out, using an external table does seem "cleaner."

                                  kshegunovK 1 Reply Last reply
                                  0
                                  • mzimmersM mzimmers

                                    @kshegunov maybe this will help describe what I'm trying to do:

                                    The controller (the hardware that hosts the application) supports a site. Within a site, there may be one or more zones (referred to as "locations" above), equipment items, and activities.

                                    One zone may use several equipment items and several activities. A given piece of equipment may support multiple zones and activities. And an activity may entail multiple zones.

                                    Based on the preceding, I don't think there is any "ownership" in the UML sense of the word.

                                    @JonB your suggestion was my original idea. But, you're right about the potential trickiness of implementation. As @SGaist pointed out, using an external table does seem "cleaner."

                                    kshegunovK Offline
                                    kshegunovK Offline
                                    kshegunov
                                    Moderators
                                    wrote on last edited by kshegunov
                                    #17

                                    From your explanation it sounds to me that the site owns everything, and also may be needed to dispatch between the different components. As far as using goes, depending on exactly what you put in this word a publish-subscribe sort of architecture that is managed by the site may be reasonable and clean.
                                    Personally, I don't think breaking encapsulation and coupling everything through some global map is a good idea. In a good architecture you couple things together only when you really need to.
                                    For example the zone may own the equipment items and activities, or perhaps the site could initialize them and inject to the zone references to the relevant object(s). Similar considerations for a piece of equipment, does it really need to know what zone and what activity is using it to be able to function? If not then it absolutely doesn't depend on them and/or the dependency if such materializes can be injected from the owner (e.g. the site) whenever the need arises.

                                    EDIT: If you're wondering what I mean by injecting the dependency in this context: https://en.wikipedia.org/wiki/Dependency_injection

                                    Read and abide by the Qt Code of Conduct

                                    mzimmersM 1 Reply Last reply
                                    2
                                    • kshegunovK kshegunov

                                      From your explanation it sounds to me that the site owns everything, and also may be needed to dispatch between the different components. As far as using goes, depending on exactly what you put in this word a publish-subscribe sort of architecture that is managed by the site may be reasonable and clean.
                                      Personally, I don't think breaking encapsulation and coupling everything through some global map is a good idea. In a good architecture you couple things together only when you really need to.
                                      For example the zone may own the equipment items and activities, or perhaps the site could initialize them and inject to the zone references to the relevant object(s). Similar considerations for a piece of equipment, does it really need to know what zone and what activity is using it to be able to function? If not then it absolutely doesn't depend on them and/or the dependency if such materializes can be injected from the owner (e.g. the site) whenever the need arises.

                                      EDIT: If you're wondering what I mean by injecting the dependency in this context: https://en.wikipedia.org/wiki/Dependency_injection

                                      mzimmersM Offline
                                      mzimmersM Offline
                                      mzimmers
                                      wrote on last edited by
                                      #18

                                      @kshegunov said in Implementing many-to-many relationships:

                                      For example the zone may own the equipment items and activities

                                      A zone will certainly use equipment and activities, but both of those could well be used in other zones. This where the notion of "ownership" becomes tricky.

                                      Similar considerations for a piece of equipment, does it really need to know what zone and what activity is using it to be able to function?

                                      Well...I'm not sure. If the user creates a schedule entry (an activity) that uses equipment A from 10 AM to noon, then later tries to create another entry from 11 AM to 1PM with the same equipment, this needs to fail. It would be cleaner if it fails at equipment selection time, so he can say "oh, OK, I'll use equipment B for this instead." Without keeping a list of activities within the equipment, I'll have to traverse all the activities in all the zones to determine this. Probably not a huge deal from a CPU standpoint, but could make for lousy code.

                                      @kshegunov said in Implementing many-to-many relationships:

                                      If not then it absolutely doesn't depend on them and/or the dependency if such materializes can be injected from the owner (e.g. the site) whenever the need arises.
                                      EDIT: If you're wondering what I mean by injecting the dependency in this context: https://en.wikipedia.org/wiki/Dependency_injection

                                      Thanks for the reference. As it turns out, I've used the assembly form of injection in the past. It seems viable for this application, provided that the number of things that require mutual awareness stays low. These lists of course will be dynamic -- when a site is initialized, all lists will be empty until equipment discovery occurs, activities are created, etc.

                                      kshegunovK 1 Reply Last reply
                                      0
                                      • mzimmersM mzimmers

                                        @kshegunov said in Implementing many-to-many relationships:

                                        For example the zone may own the equipment items and activities

                                        A zone will certainly use equipment and activities, but both of those could well be used in other zones. This where the notion of "ownership" becomes tricky.

                                        Similar considerations for a piece of equipment, does it really need to know what zone and what activity is using it to be able to function?

                                        Well...I'm not sure. If the user creates a schedule entry (an activity) that uses equipment A from 10 AM to noon, then later tries to create another entry from 11 AM to 1PM with the same equipment, this needs to fail. It would be cleaner if it fails at equipment selection time, so he can say "oh, OK, I'll use equipment B for this instead." Without keeping a list of activities within the equipment, I'll have to traverse all the activities in all the zones to determine this. Probably not a huge deal from a CPU standpoint, but could make for lousy code.

                                        @kshegunov said in Implementing many-to-many relationships:

                                        If not then it absolutely doesn't depend on them and/or the dependency if such materializes can be injected from the owner (e.g. the site) whenever the need arises.
                                        EDIT: If you're wondering what I mean by injecting the dependency in this context: https://en.wikipedia.org/wiki/Dependency_injection

                                        Thanks for the reference. As it turns out, I've used the assembly form of injection in the past. It seems viable for this application, provided that the number of things that require mutual awareness stays low. These lists of course will be dynamic -- when a site is initialized, all lists will be empty until equipment discovery occurs, activities are created, etc.

                                        kshegunovK Offline
                                        kshegunovK Offline
                                        kshegunov
                                        Moderators
                                        wrote on last edited by kshegunov
                                        #19

                                        @mzimmers said in Implementing many-to-many relationships:

                                        Well...I'm not sure. If the user creates a schedule entry (an activity) that uses equipment A from 10 AM to noon, then later tries to create another entry from 11 AM to 1PM with the same equipment, this needs to fail. It would be cleaner if it fails at equipment selection time, so he can say "oh, OK, I'll use equipment B for this instead." Without keeping a list of activities within the equipment, I'll have to traverse all the activities in all the zones to determine this. Probably not a huge deal from a CPU standpoint, but could make for lousy code.

                                        I don't follow. The equipment can keep the timeline for when it is used by anybody who reserved it. This doesn't require it to know what activities or zones or w/e it is used in. It just needs to know that somebody is going to use it at some point. You can immediately return an error if you try to reserve some equipment for some time, but it's reserved. E.g. (pseudocode)

                                        class Equipment
                                        {
                                        public:
                                             bool reserve(const TimeSlot &);
                                             void free(const TimeSlot &);
                                             bool isFree(const TimeSlot &) const;
                                        
                                        private:
                                            QVector<TimeSlot> reserved;
                                        };
                                        

                                        Then what the activity needs to keep is a list of time slots + equipment references.

                                        class Activity
                                        {
                                        public:
                                            Activity(const QVector<Equipment *> &items);
                                            bool select(Equipment *, const TimeSlot &)
                                            {
                                                // ... check if the equipment is available, insert in timeTable, etc.
                                            }
                                        
                                            QHash<TimeSlot, Equipment *> timeTable;
                                        };
                                        

                                        @mzimmers said in Implementing many-to-many relationships:

                                        I'll have to traverse all the activities in all the zones to determine this.

                                        Why? Is that the activity keeps track of when an equipment it used? Or rather I should paraphrase - should an activity manage the internal state of a piece of equipment? You could make an argument that the infotainment system in a car could control the fuel injection cycle, but then again, should it?

                                        Read and abide by the Qt Code of Conduct

                                        JonBJ Pl45m4P mzimmersM 3 Replies Last reply
                                        0
                                        • kshegunovK kshegunov

                                          @mzimmers said in Implementing many-to-many relationships:

                                          Well...I'm not sure. If the user creates a schedule entry (an activity) that uses equipment A from 10 AM to noon, then later tries to create another entry from 11 AM to 1PM with the same equipment, this needs to fail. It would be cleaner if it fails at equipment selection time, so he can say "oh, OK, I'll use equipment B for this instead." Without keeping a list of activities within the equipment, I'll have to traverse all the activities in all the zones to determine this. Probably not a huge deal from a CPU standpoint, but could make for lousy code.

                                          I don't follow. The equipment can keep the timeline for when it is used by anybody who reserved it. This doesn't require it to know what activities or zones or w/e it is used in. It just needs to know that somebody is going to use it at some point. You can immediately return an error if you try to reserve some equipment for some time, but it's reserved. E.g. (pseudocode)

                                          class Equipment
                                          {
                                          public:
                                               bool reserve(const TimeSlot &);
                                               void free(const TimeSlot &);
                                               bool isFree(const TimeSlot &) const;
                                          
                                          private:
                                              QVector<TimeSlot> reserved;
                                          };
                                          

                                          Then what the activity needs to keep is a list of time slots + equipment references.

                                          class Activity
                                          {
                                          public:
                                              Activity(const QVector<Equipment *> &items);
                                              bool select(Equipment *, const TimeSlot &)
                                              {
                                                  // ... check if the equipment is available, insert in timeTable, etc.
                                              }
                                          
                                              QHash<TimeSlot, Equipment *> timeTable;
                                          };
                                          

                                          @mzimmers said in Implementing many-to-many relationships:

                                          I'll have to traverse all the activities in all the zones to determine this.

                                          Why? Is that the activity keeps track of when an equipment it used? Or rather I should paraphrase - should an activity manage the internal state of a piece of equipment? You could make an argument that the infotainment system in a car could control the fuel injection cycle, but then again, should it?

                                          JonBJ Online
                                          JonBJ Online
                                          JonB
                                          wrote on last edited by
                                          #20

                                          @kshegunov said in Implementing many-to-many relationships:

                                          make an argument that the infotainment system in a car could control the fuel injection cycle, but then again, should it?

                                          Sometimes I think mine does in my car....

                                          1 Reply Last reply
                                          0

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved