From binghe.lisp at gmail.com Tue Apr 26 15:19:13 2011 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Tue, 26 Apr 2011 23:19:13 +0800 Subject: [elephant-devel] Is memutil necessary for ele-clp? Message-ID: Hi, dear elephant developer I saw elephant always loading a libmemutil DLL, but is this necessary if I just use the CLP backend? Thanks, Chun Tian (binghe) From eslick at media.mit.edu Tue Apr 26 16:03:38 2011 From: eslick at media.mit.edu (Ian Eslick) Date: Tue, 26 Apr 2011 09:03:38 -0700 Subject: [elephant-devel] Is memutil necessary for ele-clp? In-Reply-To: References: Message-ID: <6F7DAACC-3F0C-459A-876C-4A90E0C61360@media.mit.edu> That library primarily contains our clib-based serializer and a few utilities from the BDB backend. It's possible it's a false dependency or there is still some code in CLP that depends on the library. The key suspect is the serializer. It's been a few years since I've looked at CLP so I can't give you much more guidance than that. Thanks, Ian On Apr 26, 2011, at 8:19 AM, Chun Tian (binghe) wrote: > Hi, dear elephant developer > > I saw elephant always loading a libmemutil DLL, but is this necessary if I just use the CLP backend? > > Thanks, > > Chun Tian (binghe) > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From killerstorm at newmail.ru Tue Apr 26 17:27:54 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Tue, 26 Apr 2011 20:27:54 +0300 Subject: [elephant-devel] derived indices Message-ID: New derived index API is pretty nice, but it looks like implementation isn't quite mature. Particularly, I've encountered a problem with redefinition -- when derived index definition in class changes nothing changes. Besides that, there is no analog of rebuild-slot-indices/rebuild-slot-index for derived index. So to use them you have to do it right from start. From killerstorm at newmail.ru Tue Apr 26 21:12:11 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Wed, 27 Apr 2011 00:12:11 +0300 Subject: [elephant-devel] inherited indices Message-ID: Index inheritance is a nice feature for the case when you have several sub-classes inheriting from a common base class and you want to lookup instances by a slot value regadless of the sub-class. E.g. if super-from and mega-frob inherit from frob base class you can look up any kind of frob by frob-id if it is inherited. But what's about the case where you want to be able to do queries both among all subclasses and for a specific sub-class? id slot is probably a bad example since it is likely to be unique, so let's say we have frob-style slot. Sometimes I want get any kind of frob with a specific style: (ele:get-instances-by-value 'frob 'frob-style "vanilla") Sometimes I want to get instances of a specific class with a certain property: (ele:get-instances-by-value 'super-frob 'frob-style "vanilla") But if slot frob-style has inherited index it doesn't matter what specific class is passed to get-instances-by-value, it can return frobs and mega-frobs even if you're asking for super-frobs. I think ideally this would be resolved with a new type of 'hierarchical' slot indices where instances will be indexed in many indices at once -- when you make super-frob instance it will be indexed by frob-style both in super-frob and frob index (and, generally, in all super-classes). In this case get-instances-by-... semantics will be cleaner. But perhaps that would be rather hard to implement. As a quick fix, maybe we can filter instances on get-instances-by-... or map-inverted-index level? These functions have information about actual class so filtering instances using type-of should be trivial. Of course that will have sub-optimal performance as more instances will be pulled from database. But it is better than nothing and it fixes non-intuitive behaviour (instances of wrong type are returned if you look at it from API point of view). Users might achieve this functionality using derived indices -- say, normal frob-style slot won't have inherited index but derived slot frob-style* will be inherited and will just mirror frob-style. Thus when you want to lookup among all sub-classes you should use frob-style* instead of frob-style. But this looks a bit cumbersome in class definitions. From radisb at gmail.com Wed Apr 27 12:36:45 2011 From: radisb at gmail.com (Vassilis Radis) Date: Wed, 27 Apr 2011 15:36:45 +0300 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: Currently, I do something along the lines of the following on the results on get-instance[s]-by-XXX functions: (remove-if #'(lambda (x) (not (member ',class-name (mapcar #'class-name (sb-mop:class-precedence-list x))))) lst :key #'class-of) if I want results on the whole inheritance chain, or (remove-if #'(lambda (x) (not (equal ',class-name x)))) lst :key #'class-of) if I want result on the specific class. Now I know that efficiency is the issue here, but my (naive , since I havent had performance problems yet) response to that is that since the the search is indexed anyway, does it really matter? I mean since the complexity of the search is logarithmic wont the separate hierachical index implementation you propose have diminishing returns? This is just off the top of my head, dont throw stuff at me if I am saying something odviously stupid. Thanks, Vassilis. On Wed, Apr 27, 2011 at 12:12 AM, Alex Mizrahi wrote: > Index inheritance is a nice feature for the case when you have several > sub-classes inheriting from a common base class and you want to lookup > instances by a slot value regadless of the sub-class. > E.g. if super-from and mega-frob inherit from frob base class you can look > up any kind of frob by frob-id if it is inherited. > > But what's about the case where you want to be able to do queries both > among > all subclasses and for a specific sub-class? > > id slot is probably a bad example since it is likely to be unique, so let's > say we have frob-style slot. > > Sometimes I want get any kind of frob with a specific style: > > (ele:get-instances-by-value 'frob 'frob-style "vanilla") > > Sometimes I want to get instances of a specific class with a certain > property: > > (ele:get-instances-by-value 'super-frob 'frob-style "vanilla") > > But if slot frob-style has inherited index it doesn't matter what specific > class is passed to get-instances-by-value, it can return frobs and > mega-frobs even if you're asking for super-frobs. > > I think ideally this would be resolved with a new type of 'hierarchical' > slot indices where instances will be indexed in many indices at once -- > when > you make super-frob instance it will be indexed by frob-style both in > super-frob and frob index (and, generally, in all super-classes). In this > case get-instances-by-... semantics will be cleaner. > > But perhaps that would be rather hard to implement. > > As a quick fix, maybe we can filter instances on get-instances-by-... or > map-inverted-index level? > These functions have information about actual class so filtering instances > using type-of should be trivial. > > Of course that will have sub-optimal performance as more instances will be > pulled from database. > But it is better than nothing and it fixes non-intuitive behaviour > (instances of wrong type are returned if you look at it from API point of > view). > > Users might achieve this functionality using derived indices -- say, normal > frob-style slot won't have inherited index but derived slot frob-style* > will > be inherited and will just mirror frob-style. Thus when you want to lookup > among all sub-classes you should use frob-style* instead of frob-style. > But this looks a bit cumbersome in class definitions. > > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From killerstorm at newmail.ru Wed Apr 27 19:34:34 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Wed, 27 Apr 2011 22:34:34 +0300 Subject: [elephant-devel] inherited indices References: Message-ID: > Currently, I do something along the lines of the following on the results > on get-instance[s]-by-XXX functions: > (remove-if #'(lambda (x) (not (member ',class-name (mapcar #'class-name > (sb-mop:class-precedence-list x))))) lst :key #'class-of) > if I want results on the whole inheritance chain, or > (remove-if #'(lambda (x) (not (equal ',class-name x)))) lst :key > #'class-of) if I want result on the specific class. I wonder why not just typep? It should be enough to answer any reasonable class-related query. > Now I know that efficiency is the issue here, but my (naive , since I > havent had performance problems yet) response to that is that since the > the search is indexed anyway, does it really matter? > I mean since the complexity of the search is logarithmic wont the separate > hierachical index implementation you propose have diminishing returns? If you consider only search then yes, in theory there should be no significant difference. But if multiple instances are returned you'll just have more data read and sent to the Lisp side, so it will be proportionally slower. Le'ts consider a situation when you have one base class and M subclasses, and each subclass has N instances matching a query on average. Then with simple inherited index you'll have N*M instances read from database, while direct index on subclass would return only N. Thus M times more data is read. But it depends on expected value of N. If it is low (e.g N*M<1) then query time will be dominated by search but not data read or transfer. So it doesn't matter in this case. But if you queries you run typically return many instances it might be a problem. From radisb at gmail.com Thu Apr 28 08:16:49 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 28 Apr 2011 11:16:49 +0300 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: On Wed, Apr 27, 2011 at 10:34 PM, Alex Mizrahi wrote: > > Currently, I do something along the lines of the following on the results > > on get-instance[s]-by-XXX functions: > > (remove-if #'(lambda (x) (not (member ',class-name (mapcar #'class-name > > (sb-mop:class-precedence-list x))))) lst :key #'class-of) > > if I want results on the whole inheritance chain, or > > (remove-if #'(lambda (x) (not (equal ',class-name x)))) lst :key > > #'class-of) if I want result on the specific class. > > I wonder why not just typep? > It should be enough to answer any reasonable class-related query. Yes I was wondering the same thing yesterday... Lisp newbie here. Not well acquainted with the tools yet :) > > Now I know that efficiency is the issue here, but my (naive , since I > > havent had performance problems yet) response to that is that since the > > the search is indexed anyway, does it really matter? > > I mean since the complexity of the search is logarithmic wont the > separate > > hierachical index implementation you propose have diminishing returns? > > If you consider only search then yes, in theory there should be no > significant difference. > > But if multiple instances are returned you'll just have more data read and > sent to the Lisp side, so it will be proportionally slower. > > Le'ts consider a situation when you have one base class and M subclasses, > and each subclass has N instances matching a query on average. > Then with simple inherited index you'll have N*M instances read from > database, while direct index on subclass would return only N. > Thus M times more data is read. > I totally agree with the rationale. How realistic this simple estimate is, I agree (as you imply below) depends on the application. > But it depends on expected value of N. If it is low (e.g N*M<1) then query > time will be dominated by search but not data read or transfer. So it > doesn't matter in this case. > But if you queries you run typically return many instances it might be a > problem. You mean many instances of the subclasses dont you? _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Apr 28 09:29:57 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 28 Apr 2011 12:29:57 +0300 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: I think ideally this would be resolved with a new type of 'hierarchical' > slot indices where instances will be indexed in many indices at once -- > when > you make super-frob instance it will be indexed by frob-style both in > super-frob and frob index (and, generally, in all super-classes). In this > case get-instances-by-... semantics will be cleaner. > > > But perhaps that would be rather hard to implement. > Why? I am by no means an expert and never looked thoroughly the code, but ,abstractly speaking, doesnt it boil down to just creating more indexes automatically at class definition time? > > As a quick fix, maybe we can filter instances on get-instances-by-... or > map-inverted-index level? > These functions have information about actual class so filtering instances > using type-of should be trivial. Independently of the whole subject, I think this should be done anyway, and it can be an optional param with a default for old behaviour for those who want the whole pie. I think many people subtypep the results of get-instance family funcs early in their projects. Vassilis. > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Apr 28 12:48:27 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 28 Apr 2011 15:48:27 +0300 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? Message-ID: After creating a lot of objects of a specific class I decided to change a slot to be indexed. It did change, no old items were included in the index. How can I populate the index with old values? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at media.mit.edu Thu Apr 28 12:57:05 2011 From: eslick at media.mit.edu (Ian Eslick) Date: Thu, 28 Apr 2011 05:57:05 -0700 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? In-Reply-To: References: Message-ID: <88468A07-EF83-4F3F-A7BC-2E43D3EDB881@media.mit.edu> I assume you added :index and didn't change the slot name? I think the function you want is recreate-index-using-class On Apr 28, 2011, at 5:48 AM, Vassilis Radis wrote: > After creating a lot of objects of a specific class I decided to change a slot to be indexed. It did change, no old items were included in the index. How can I populate the index with old values? _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From killerstorm at newmail.ru Thu Apr 28 15:10:07 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Thu, 28 Apr 2011 18:10:07 +0300 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? References: Message-ID: > After creating a lot of objects of a specific class I decided to change a > slot to be indexed. > It did change, no old items were included in the index. Isn't this a bug? > How can I populate the index with old values? (defmethod rebuild-slot-index ((sc store-controller) class-name index-name) (defun rebuild-slot-indices (sc class) Doesn't work for derived indices, though. From eslick at media.mit.edu Thu Apr 28 15:39:02 2011 From: eslick at media.mit.edu (Ian Eslick) Date: Thu, 28 Apr 2011 08:39:02 -0700 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? In-Reply-To: References: Message-ID: <852EF08C-2473-42A2-BA82-A2715F1069A7@media.mit.edu> Hi everyone, I'm not going to be in a position to do regular development or support for Elephant for at least the next year. I may be able to make small, critical bug fixes or apply patches if no one else steps up. Leslie and Alex are both capable of making changes and improvements and I'm happy to give checkin privs if they're interested (I think Leslie has them already). Also, if someone wants to step up as maintainer I'm happy to step down, but will hold the fort as best I can otherwise. Thank you, Ian On Apr 28, 2011, at 8:10 AM, Alex Mizrahi wrote: >> After creating a lot of objects of a specific class I decided to change a >> slot to be indexed. >> It did change, no old items were included in the index. > > Isn't this a bug? > >> How can I populate the index with old values? > > (defmethod rebuild-slot-index ((sc store-controller) class-name index-name) > (defun rebuild-slot-indices (sc class) > > Doesn't work for derived indices, though. > > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From killerstorm at newmail.ru Thu Apr 28 16:31:59 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Thu, 28 Apr 2011 19:31:59 +0300 Subject: [elephant-devel] inherited indices References: Message-ID: > Why? I am by no means an expert and never looked thoroughly the code, > but ,abstractly speaking, doesnt it boil down to just creating > more indexes automatically at class definition time? Code assumes that there is only one index it needs to update at time, so it needs to be revised to handle many of them. Nothing particularly hard, but it requires some code rewriting and thus While another alternative is pretty much trivial. > Independently of the whole subject, I think this should be done anyway, > and it can be an optional param with a default for old behaviour for those > who want the whole pie. > I think many people subtypep the results of get-instance family funcs > early in their projects. I don't think that 'old behaviour' was intentional, people should not depend on query for one sub-class returning instances of another sub-class. And it is trivial to fix it -- just pass super-class instead of sub-class to this function if you want all instances. So I think get-instances-by-... should unconditionally do the filtering. While map-inverted-index probably shouldn't do the filtering. I consider it a lower-level API which works with index directly, without a promise to return instances of certain class. And also implementing it at that level is somewhat harder. From eslick at media.mit.edu Thu Apr 28 17:34:16 2011 From: eslick at media.mit.edu (Ian Eslick) Date: Thu, 28 Apr 2011 10:34:16 -0700 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: I agree the semantics of inherited indexing is off. I implemented what worked for me at the time and was an easy extension to what was already there. However, the issues around class redefinition, database connection state, schema synchronization, data loss protection, etc make code changes around index management a trickier than you'd think. One solution is to get rid of the :inherited option and simply allow a :subclasses? option to get-instances-by-value/range that uses the mop to find subclass indexes and does a merge sort of all objects returned by the various indexes. This becomes time O(k log_b n) and gets rid of inherited indexing. However, if the k is going to matter or you want a faster option, you can keep :inherited (one big index) and have get-instances-by--value/range filter out classes you didn't ask for (i.e if base class get everything, if asking for subclass and inherited then just return matching subclasses - you could even do this before object instantiation to make it extremely efficient by testing the schema ID associated with the OID (checking for older schemas that need to be upgraded if schema upgrading is set to lazy) Ian On Apr 28, 2011, at 9:31 AM, Alex Mizrahi wrote: >> Why? I am by no means an expert and never looked thoroughly the code, >> but ,abstractly speaking, doesnt it boil down to just creating >> more indexes automatically at class definition time? > > Code assumes that there is only one index it needs to update at time, so it > needs to be revised to handle many of them. > Nothing particularly hard, but it requires some code rewriting and thus > > While another alternative is pretty much trivial. > >> Independently of the whole subject, I think this should be done anyway, >> and it can be an optional param with a default for old behaviour for those >> who want the whole pie. >> I think many people subtypep the results of get-instance family funcs >> early in their projects. > > I don't think that 'old behaviour' was intentional, people should not depend > on query for one sub-class returning instances of another sub-class. > And it is trivial to fix it -- just pass super-class instead of sub-class to > this function if you want all instances. > > So I think get-instances-by-... should unconditionally do the filtering. > > While map-inverted-index probably shouldn't do the filtering. I consider it > a lower-level API which works with index directly, without a promise to > return instances of certain class. > And also implementing it at that level is somewhat harder. > > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From radisb at gmail.com Thu Apr 28 20:46:06 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 28 Apr 2011 23:46:06 +0300 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? In-Reply-To: <852EF08C-2473-42A2-BA82-A2715F1069A7@media.mit.edu> References: <852EF08C-2473-42A2-BA82-A2715F1069A7@media.mit.edu> Message-ID: Oh come on... What happened? Anyway, for you to be able to foresee for a whole year it means it is serious. I wish best luck. On Thu, Apr 28, 2011 at 6:39 PM, Ian Eslick wrote: > Hi everyone, > > I'm not going to be in a position to do regular development or support for > Elephant for at least the next year. I may be able to make small, critical > bug fixes or apply patches if no one else steps up. > > Leslie and Alex are both capable of making changes and improvements and I'm > happy to give checkin privs if they're interested (I think Leslie has them > already). Also, if someone wants to step up as maintainer I'm happy to step > down, but will hold the fort as best I can otherwise. > > Thank you, > Ian > > On Apr 28, 2011, at 8:10 AM, Alex Mizrahi wrote: > > >> After creating a lot of objects of a specific class I decided to change > a > >> slot to be indexed. > >> It did change, no old items were included in the index. > > > > Isn't this a bug? > > > >> How can I populate the index with old values? > > > > (defmethod rebuild-slot-index ((sc store-controller) class-name > index-name) > > (defun rebuild-slot-indices (sc class) > > > > Doesn't work for derived indices, though. > > > > > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Apr 28 20:51:58 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 28 Apr 2011 23:51:58 +0300 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? In-Reply-To: References: Message-ID: As Ian correctly assumed, I just added the :index t . I didnt change the slot name. So, candidates are: rebuild-slot-index recreate-index-using-class I am going to look at them. Thanks. P.S. As Alex asked, is this a bug or is the normal functionality? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at media.mit.edu Thu Apr 28 20:54:39 2011 From: eslick at media.mit.edu (Ian Eslick) Date: Thu, 28 Apr 2011 13:54:39 -0700 Subject: [elephant-devel] How do I populate an index of a slot that was created later with values created before slot became indexed? In-Reply-To: References: Message-ID: <0F69730D-4D0D-4115-AC9C-0CDD5E85C31D@media.mit.edu> Clearly a bug if the instances aren't getting indexed when you add an index! Should be a simple one to fix. The older you get, sadly, the easier it is to do long-term forecasting. :) Ian On Apr 28, 2011, at 1:51 PM, Vassilis Radis wrote: > As Ian correctly assumed, I just added the :index t . I didnt change the slot name. > > So, candidates are: > > rebuild-slot-index > recreate-index-using-class > > I am going to look at them. Thanks. > > P.S. As Alex asked, is this a bug or is the normal functionality? > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Apr 28 21:25:44 2011 From: radisb at gmail.com (Vassilis Radis) Date: Fri, 29 Apr 2011 00:25:44 +0300 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: On Thu, Apr 28, 2011 at 8:34 PM, Ian Eslick wrote: > I agree the semantics of inherited indexing is off. I implemented what > worked for me at the time and was an easy extension to what was already > there. However, the issues around class redefinition, database connection > state, schema synchronization, data loss protection, etc make code changes > around index management a trickier than you'd think. > > One solution is to get rid of the :inherited option and simply allow a > :subclasses? option to get-instances-by-value/range that uses the mop to > find subclass indexes and does a merge sort of all objects returned by the > various indexes. This becomes time O(k log_b n) and gets rid of inherited > indexing. > > I like this. > However, if the k is going to matter or you want a faster option, you can > keep :inherited (one big index) and have get-instances-by--value/range > filter out classes you didn't ask for (i.e if base class get everything, if > asking for subclass and inherited then just return matching subclasses - If i understand correctly, Alex suggests that this for some (many?) cases could actually be slow if query returns many unwanted instances for reasons after searching > you could even do this before object instantiation to make it extremely > efficient by testing the schema ID associated with the OID (checking for > older schemas that need to be upgraded if schema upgrading is set to lazy) > > And if I understand correctly again , this deals with Alex's concern, right? But I like the first idea better, because it gets rid of indexed inheriting and combines the best of the two worlds: When we want many classes, fetch and read only those we want (and not all the tree and then filter), and when we want one fetch only that one. Well the first is correct assuming that fetching all the tree and filtering the instances is slower than merge sorting the instances. Any rough estimates on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Apr 28 22:07:02 2011 From: radisb at gmail.com (Vassilis Radis) Date: Fri, 29 Apr 2011 01:07:02 +0300 Subject: [elephant-devel] inherited indices In-Reply-To: References: Message-ID: On Thu, Apr 28, 2011 at 7:31 PM, Alex Mizrahi wrote: > > Why? I am by no means an expert and never looked thoroughly the code, > > but ,abstractly speaking, doesnt it boil down to just creating > > more indexes automatically at class definition time? > > Code assumes that there is only one index it needs to update at time, so it > needs to be revised to handle many of them. > Nothing particularly hard, but it requires some code rewriting and thus > > While another alternative is pretty much trivial. > > > Independently of the whole subject, I think this should be done anyway, > > and it can be an optional param with a default for old behaviour for > those > > who want the whole pie. > > I think many people subtypep the results of get-instance family funcs > > early in their projects. > > I don't think that 'old behaviour' was intentional, people should not > depend > on query for one sub-class returning instances of another sub-class. > And it is trivial to fix it -- just pass super-class instead of sub-class > to > this function if you want all instances. > > So I think get-instances-by-... should unconditionally do the filtering. You are right then. > While map-inverted-index probably shouldn't do the filtering. I consider it > a lower-level API which works with index directly, without a promise to > return instances of certain class. > And also implementing it at that level is somewhat harder. > > Totally agree with that. From the index point of view, class hierarchy relationships are irrelevant and even non existent, since at that level the only distinguishable relationship is the key-value one. It would be wrong to inject such semantics at that level. > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: