Thread: [Modeling-users] Raw Qualifiers
Status: Abandoned
Brought to you by:
sbigaret
From: Yannick G. <yan...@sa...> - 2003-07-15 19:30:41
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone,=20 I'd like to share with you the joy of building qualifiers by hand. The use we have for the framework here is really dependent on performance. So we looked at those profiler logs and asked Seb why spark was sucking so much juice. Promptly we found out that spark was slow because it was flexible but it is possible to make Qualifier by hand without passing by the ugly string to parse. Unfortunately all this nice magic is undocumented right now : ( So it goes like this : There is a bunch of operator out there, somewhere in Qualifier.py or if you prefer Modeling.Qualifier. The operators are exactly the ones you would expect to use the in the query string : QualifierOperatorEqual for "=3D=3D", QualifierOperatorLessThan for "<", QualifierOperatorLike for "like" and so on. The main idea is to build some qualifiers that put those operators in relation with your model. I used Qualifier.KeyValueQualifier but you may want to try KeyComparisonQualifier too. that part is easy, you create some qualifiers instances with a key, an operator and a value: # match all the authors who's name start with "H" qual1 =3D KeyValueQualifier( "name",=20 QualifierOperatorLike, "H*" ) # match only young authors qual2 =3D KeyValueQualifier( "age", QualifierOperatorLessThan, 35 ) # match the authors who's name ends with "s" qual3 =3D KeyValueQualifier( "age", QualifierOperatorLike, "*s" ) And now that I'm done with the qualifier, I simply need to put them togethe= r : # I don't like authors who's name ends with "s" qual4 =3D NotQualifier(qual4) # pack all of those in a single qualifier allQuals =3D (qual1, qual2, qual4) # any sequence (list of tuple) will do qual5 =3D AndQualifier(allQuals) And finally do the fetch: objs =3D ec.fetch("author", qual5) Or the super fast: dicts =3D ec.fetch("author", qual5, rawRow=3D1) Nice isn't it ? So how fast is it ? Twice as fast on my data, you millage may vary. : ) So I hope this will help you all to get the best out of the framework. The best source of doc is not the doc, the doc may get a bit out of synch. Dive into those sources up to the unit tests. S=E9bastien works hard to get all of those working all the time so you're sure to find a lot of working example there. Enjoy ! =2D --=20 Yannick Gingras Byte Gardener, Savoir-faire Linux inc. (514) 276-5468 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/FFZerhy5Fqn/MRARArdcAJ0T83mw1ZHCqjEOo000kE9XUXdIxwCfRppm wYlFWKyPGPMNy0uYEz8kpqk=3D =3DkiXC =2D----END PGP SIGNATURE----- |
From: Sebastien B. <sbi...@us...> - 2003-07-16 12:13:37
|
Thanks a lot Yannick for this nice clarification. I'll probably include your message as-is in the documentation until I find some time to rewrite it (I already have quite a bunch of doc. to write, and you now know what happens when I have too much doc. to write: I had features, which implies even more doc. to write, but well, that's my delaying tactics ;). Little disgression: the very reason why I made the QualifierParser, then documented it only, is historically bound to the somewhat complex API for fetching objects; before we get the current ec.fetch(), fetching implied qualifierWithQualifierFormat, FetchSpecification and ec.objectsWithFetchSpecification(). People were not finding it that handy/friendly, imagine their groans if I had put on top of that step-by-step instructions to build qualifiers! > So I hope this will help you all to get the best out of the framework. > The best source of doc is not the doc, the doc may get a bit out of > synch. Dive into those sources up to the unit tests. S=E9bastien works > hard to get all of those working all the time so you're sure to find a > lot of working example there. Writing docs in very time-consuming, and writing *good* doc. is more then that ;) Hopefully it's not that bad... About unittests: yes, I maintain then very strictly. Mostly every bug gets its unittests before being fixed (even if I rarely expose them in patches), new features get unittests before I start coding, so you can definitely rely on them. -- S=E9bastien. |
From: Yannick G. <ygi...@yg...> - 2003-07-16 12:54:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 16 July 2003 08:13, Sebastien Bigaret wrote: > Thanks a lot Yannick for this nice clarification. I'll probably > include your message as-is in the documentation until I find some time > to rewrite it No problem. And as I asked in private why LaTex instead of DocBook ? DocBook is a really simple mark up with implied support for unicode since it's XML. 30 different tags max in a regular document. KDE, Gnome, Python and Linux are all moving to DocBook. I would have put it the mark up myself but this LaTex thing is beyond my mere mortal capabilities. ; ) > (I already have quite a bunch of doc. to write, and you > now know what happens when I have too much doc. to write: I had > features, which implies even more doc. to write, but well, that's my > delaying tactics ;). Everyone needs a bit of entertainment !=20 : D > Little disgression: the very reason why I made the QualifierParser, > then documented it only, is historically bound to the somewhat > complex API for fetching objects; before we get the current > ec.fetch(), fetching implied qualifierWithQualifierFormat, > FetchSpecification and ec.objectsWithFetchSpecification(). People > were not finding it that handy/friendly, imagine their groans if I > had put on top of that step-by-step instructions to build > qualifiers! They would have hunt you down to poke your eyes ! Well, I would have done just that... ; ) > > So I hope this will help you all to get the best out of the framework. > > The best source of doc is not the doc, the doc may get a bit out of > > synch. Dive into those sources up to the unit tests. S=E9bastien wo= rks > > hard to get all of those working all the time so you're sure to find = a > > lot of working example there. > > Writing docs in very time-consuming, and writing *good* doc. is more > then that ;) Hopefully it's not that bad... > > About unittests: yes, I maintain then very strictly. Mostly every bug > gets its unittests before being fixed (even if I rarely expose them in > patches), new features get unittests before I start coding, so you can > definitely rely on them. No the doc is not that bad. This is just a reminder that code is meant to be read by both human and computers. Furthermore, a good programming language will be more expressive that english. How many words to explain "(%s)" % ", ".join(map(str, aList)) ? But it's still quite readable. When you can't find it in the doc, or when the doc is unclear, do a quick grep. It might be obvious in Python. The case of the unit tests is really special. The fact that those are your quality assurance kit means that they are guaranteed to work. There is in those tests an amazing amount of working example and we need just that : a picture. I think that the doc should mention them, they are more valuable than you think. Regards,=20 - --=20 Yannick Gingras Coder for OBB : Out Biconcave Beingness http://OpenBeatBox.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/FNYlrhy5Fqn/MRARAgTBAJ9jc+uJnMBQoO7xUb5JoQilss6NEwCfUo8O dY3FlKFQwdqOSCAj7lvBHrg=3D =3DftmW -----END PGP SIGNATURE----- |
From: Sebastien B. <sbi...@us...> - 2003-07-17 12:38:39
|
Yannick Gingras <ygi...@yg...> wrote: > No problem. And as I asked in private why LaTex instead of DocBook ? > DocBook is a really simple mark up with implied support for unicode > since it's XML. 30 different tags max in a regular document. KDE, > Gnome, Python and Linux are all moving to DocBook. I would have put > it the mark up myself but this LaTex thing is beyond my mere mortal > capabilities. [laziness speaking] I couldn't find a reference for python/docbook, do you have any? Why latex? Because I know latex for years and have never tried docbook, that's as simple. Moreover, I've found the python documentation process, based on latex, quite handy to generate docs in html/pdf. And well, before considering a migration, I'd better have a look at docbook itself. > No the doc is not that bad. This is just a reminder that code is > meant to be read by both human and computers. Furthermore, a good > programming language will be more expressive that english. [...] > The case of the unit tests is really special. The fact that those are > your quality assurance kit means that they are guaranteed to work. > There is in those tests an amazing amount of working example and we need > just that : a picture. I think that the doc should mention them, they > are more valuable than you think. You're probably right. However this is already there in the doc, admittedly in little characters, at http://modeling.sf.net/UserGuide/ec-object-uniquing.html, I'll see how I can make this more proeminent. Regards, -- S=E9bastien. |