Thread: [Refdb-devel] Once more the ruby bindings
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-devel
|
From: Sebastian H. <seb...@ii...> - 2006-04-10 09:53:34
Attachments:
smime.p7s
|
Hi, I have an account on sourceforge: yhirmikq Is it a known issue or just a problem with my configuration, that notes do not work with the current release? A snippet from the log reveals the error: AND ORDER BY t_note.note_id 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDER BY t_note.note_id' at line 1 There is the search string missing the sql command. Is this working for you? I am currently rewriting and updating the bindings, they are rather out of date :-( Greetings, Sebastian -- Sebastian Höhn <ho...@ii...> Institut für Informatik und Gesellschaft, Abteilung Telematik Universität Freiburg Telefon: +49 761 203 4950 Friedrichstraße 50, D-79098 Freiburg Fax: -4929, Sek: -4964 ----- IIG im WWW: http://www.telematik.uni-freiburg.de ----- |
|
From: Markus H. <mar...@mh...> - 2006-04-10 20:53:08
|
Hi, Sebastian Hoehn writes: > I have an account on sourceforge: yhirmikq > I should have asked in the first place: would you prefer to develop your stuff as a part of the RefDB project, or would you like to start an independent SourceForge project? Either way is fine with me, just let me know. > Is it a known issue or just a problem with my configuration, that notes > do not work with the current release? > > A snippet from the log reveals the error: > > AND ORDER BY t_note.note_id > 1064: You have an error in your SQL syntax; check the manual that > corresponds to your MySQL server version for the right syntax to use > near 'ORDER BY t_note.note_id' at line 1 > > There is the search string missing the sql command. Is this working for you? > My test script runs ok, including adding, retrieving, and deleting notes. Would you mind sharing some more information about this problem? What do the notes look like? What queries do you run? What is the context in the log file (i.e. starting from the getnote command)? > > I am currently rewriting and updating the bindings, they are rather out > of date :-( > Yes, this is very likely. Diwaker mentioned that his code was lying around for half a year before he donated it, and that's also a while ago. Hope it's not too much hassle to update the stuff. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Sebastian H. <seb...@ii...> - 2006-04-11 08:34:13
Attachments:
smime.p7s
|
Markus Hoenicka wrote: > Hi, > > Sebastian Hoehn writes: > > I have an account on sourceforge: yhirmikq > > > > I should have asked in the first place: would you prefer to develop > your stuff as a part of the RefDB project, or would you like to start > an independent SourceForge project? Either way is fine with me, just let > me know. > It is a good idea to start a new project, so that I can do some additional stuff ;-) I currently update the existing ruby bindings. That is fine and I hope will be finished soon. Furthermore I currently think about a SOAP bindings implemented in Ruby to access the refdb database. This will deliver a standards compliant interface to the server and deserve as a good starting point for future interfaces. Furthermore the ruby on rails webapp will be part of the new project. I am still thinking about accessing the database directly from the webapp. What is the pros and cons of additionally involving the current c-client and server? The same is true for the possible implementation of the soap bindings. Are there any advantages of additionally involving that server? No matter, the current client and server are great and really appreciate the emacs interface, but I wish to establish a central ref database here at work and not everybody will be satisfied with that interface. So the question is: should the webapp for managing the references work directly with the database or is it better to interact with the current server? For two reasons I am in favor of the "direct approach" for the web app: - We reduce the number of bugs, there are just the webapp and mysql/pgsql/sqlite bugs, no server bugs - We enhance performance, since all the queries can be executed directly There certainly is a disadvantage, too: - There is no support for ris, risx, bibtex and so on. I see the disadvantage not too bad, because the code exists and can be integrated in the project as is. I am glad to hear your opinion on the topic. The new project I will register with sourceforge will be called refdbonrails > My test script runs ok, including adding, retrieving, and deleting > notes. Would you mind sharing some more information about this > problem? What do the notes look like? What queries do you run? What is > the context in the log file (i.e. starting from the getnote command)? > These are among the issues I dislike with the current server. The communication is rather complicated and these errors cannot be reproduced. I currently have two refdb servers running for testing the ruby bindings and if one fails, the other works ;-) > > > > I am currently rewriting and updating the bindings, they are rather out > > of date :-( > > > > Yes, this is very likely. Diwaker mentioned that his code was lying > around for half a year before he donated it, and that's also a while > ago. Hope it's not too much hassle to update the stuff. > It is alright, because I have the great perl module and I can stick with that if the protocols of Diwaker are out of date. The code snippets Diwaker provided are working great. So this is just a resembling of the current sources. Regards, Sebastian |
|
From: Markus H. <mar...@mh...> - 2006-04-11 11:42:28
|
Sebastian Hoehn <seb...@ii...> was heard to say: > It is a good idea to start a new project, so that I can do some > additional stuff ;-) > Fine with me. > I currently update the existing ruby bindings. That is fine and I hope > will be finished soon. > Furthermore I currently think about a SOAP bindings implemented in Ruby > to access the refdb database. This will deliver a standards compliant > interface to the server and deserve as a good starting point for future > interfaces. > Sounds cool. What about SRW? I thought implementing an SRW interface using Indexdata's SimpleServer, but if it is trivial to add this functionality to your SOAP code you might as well do it. > Furthermore the ruby on rails webapp will be part of the new project. I > am still thinking about accessing the database directly from the webapp. > What is the pros and cons of additionally involving the current c-client > and server? The same is true for the possible implementation of the soap > bindings. Are there any advantages of additionally involving that > server? No matter, the current client and server are great and really > appreciate the emacs interface, but I wish to establish a central ref > database here at work and not everybody will be satisfied with that > interface. So the question is: should the webapp for managing the > references work directly with the database or is it better to interact > with the current server? > > For two reasons I am in favor of the "direct approach" for the web app: > > - We reduce the number of bugs, there are just the webapp and > mysql/pgsql/sqlite bugs, no server bugs > - We enhance performance, since all the queries can be executed directly > > There certainly is a disadvantage, too: > - There is no support for ris, risx, bibtex and so on. > I went through this a couple of times in the past, but it doesn't hurt to reiterate the issues here. You should be aware that refdbd does more than just map RIS lines to database fields, dumping whatever it receives. refdbd has to take apart some of the data (e.g authors, dates), normalize data (author names, journal titles, scan data for keywords. If you bypass refdbd, - you'll have to reimplement this code in Ruby. Instead of avoiding the server bugs, you'll just add new bugs, increasing the overall number of bugs. - you may end up with two slightly different implementations. I do get the very same results on the command line, in refdb-mode, and in any Perl script that uses the RefDBClient module. If your new code does not use exactly the same algorithms (including the same bugs), your data will depend on how you add them to or retrieve them from the database. - you'll have to change your code whenever I do. I'm just compiling a proposal how to extend the RIS model to make it easier to implement and understand. This will require thorough changes to the SQL database schemas. I'm sure that I can implement these changes without affecting the client-server interface or the client functions. If you want to access the tables directly, you can dump half of your code right after you've implemented it. If you go through refdbd, you'll probably get away with cosmetic fixes in the interface to better support the new data model. It should be obvious that two implementations maintained by two different projects will almost always be out of sync. Taken together, I don't see an advantage that direct table access may provide. I'd strongly recommend to use Diwaker's code to talk to refdbd instead of to the database engines. You'll get 90% of the nasty code for free, you'll program agains a fairly stable interface, and you can concentrate on providing a good interface instead of reinventing my bugs. > The new project I will register with sourceforge will be called refdbonrails > A cool name is half the fare... > These are among the issues I dislike with the current server. The > communication is rather complicated and these errors cannot be > reproduced. I currently have two refdb servers running for testing the > ruby bindings and if one fails, the other works ;-) > > > I'd suspect that there is some problem with the ruby code. I did not experience this kind of problems with either the C clients or the Perl module. Can you reproduce the problems with one of these clients? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Sebastian H. <seb...@ii...> - 2006-04-11 12:04:54
Attachments:
smime.p7s
|
I guess I will stick to the c client then for the interface. I just thought using ruby on rails great out of the box database support could be of great help for my implementation. But you are right with the data processing that is done despite the simple SQL data access. Then these projects will never get out of sync. I nevertheless think about a different way of integrating all that behind a soap interface, perhaps by calling your C procedures directly, then I do not need to make any changes even if the protocol changes. Markus Hoenicka wrote: > I'd suspect that there is some problem with the ruby code. I did not experience > this kind of problems with either the C clients or the Perl module. Can you > reproduce the problems with one of these clients? > This is with the C Client. The note I've sent was the example from the sources. I do not have the time right now to further investigate this, perhaps I can solve this by myself. Regards, Sebastian |
|
From: Bruce D'A. <bru...@Op...> - 2006-04-11 12:20:24
|
On Apr 11, 2006, at 7:42 AM, Markus Hoenicka wrote: >> Furthermore I currently think about a SOAP bindings implemented in >> Ruby >> to access the refdb database. This will deliver a standards compliant >> interface to the server and deserve as a good starting point for >> future >> interfaces. > > Sounds cool. What about SRW? I thought implementing an SRW interface > using > Indexdata's SimpleServer, but if it is trivial to add this > functionality to > your SOAP code you might as well do it. Yikes. Sebastian, why would you use SOAP? A RESTful approach like SRU or the new unAPI would be much simpler all around. >> Furthermore the ruby on rails webapp will be part of the new project. >> I >> am still thinking about accessing the database directly from the >> webapp. Yeah, I was wondering when you were going to say this. The whole point of Rails is really the OO-relational mapping. And then you start to wonder what you have that is still "RefDB." > - you'll have to change your code whenever I do. I'm just compiling a > proposal > how to extend the RIS model to make it easier to implement and > understand. This > will require thorough changes to the SQL database schemas. What changes are you contemplating to the SQL model Markus? FWIW, I've come to the conclusion that reference data really comes down to these primary entities: Reference (anything citable), Collection (periodicals, archival collections, series), Event (workshops, conferences, etc.), and Contributor (authors, publishers, translator, etc.). When you remove the requirement that all data must fit in a level model, then you offer more flexibility: horizontal relations such as a translation to an original, a speech presented at some event, etc. Bruce |
|
From: Bruce D'A. <bd...@gm...> - 2006-04-11 12:26:53
|
On Apr 11, 2006, at 7:42 AM, Markus Hoenicka wrote: >> Furthermore I currently think about a SOAP bindings implemented in >> Ruby >> to access the refdb database. This will deliver a standards compliant >> interface to the server and deserve as a good starting point for >> future >> interfaces. > > Sounds cool. What about SRW? I thought implementing an SRW interface > using > Indexdata's SimpleServer, but if it is trivial to add this > functionality to > your SOAP code you might as well do it. Yikes. Sebastian, why would you use SOAP? A RESTful approach like SRU or the new unAPI would be much simpler all around. >> Furthermore the ruby on rails webapp will be part of the new project. >> I >> am still thinking about accessing the database directly from the >> webapp. Yeah, I was wondering when you were going to say this. The whole point of Rails is really the OO-relational mapping. And then you start to wonder what you have that is still "RefDB." > - you'll have to change your code whenever I do. I'm just compiling a > proposal > how to extend the RIS model to make it easier to implement and > understand. This > will require thorough changes to the SQL database schemas. What changes are you contemplating to the SQL model Markus? FWIW, I've come to the conclusion that reference data really comes down to these primary entities: Reference (anything citable), Collection (periodicals, archival collections, series), Event (workshops, conferences, etc.), and Contributor (authors, publishers, translator, etc.). When you remove the requirement that all data must fit in a level model, then you offer more flexibility: horizontal relations such as a translation to an original, a speech presented at some event, etc. Bruce |
|
From: Sebastian H. <seb...@ii...> - 2006-04-11 13:49:47
Attachments:
smime.p7s
|
Bruce D'Arcus wrote: > > On Apr 11, 2006, at 7:42 AM, Markus Hoenicka wrote: > >>> Furthermore I currently think about a SOAP bindings implemented in Ruby >>> to access the refdb database. This will deliver a standards compliant >>> interface to the server and deserve as a good starting point for future >>> interfaces. >> >> Sounds cool. What about SRW? I thought implementing an SRW interface >> using >> Indexdata's SimpleServer, but if it is trivial to add this >> functionality to >> your SOAP code you might as well do it. > > Yikes. Sebastian, why would you use SOAP? A RESTful approach like SRU > or the new unAPI would be much simpler all around. This is because SOAP comes for "free" with ruby. I just need to write one class with the adequate functions and register it with the SOAP server. The server comes with standard ruby. The same is true for the client I just need to create a proxy object and the rest is automagically done. I don't know who said this, but it is true in this discussion: "The good thing about standards is that there are so many to choose from" ;-) I will do a SOAP interface (the main reason: I know how to do it and it is simple), we can discuss the rest later on. >>> Furthermore the ruby on rails webapp will be part of the new project. I >>> am still thinking about accessing the database directly from the >>> webapp. > > Yeah, I was wondering when you were going to say this. The whole point > of Rails is really the OO-relational mapping. And then you start to > wonder what you have that is still "RefDB." I didn't wonder what is still refdb, since we have all the client tools, that generate bibfiles, integrate into xml editing for emacs and so on. Perhaps the webapp is just another "view" on the database? All this stuff is not part of the webapp. I am still not very sure whether ruby and particularly rails should not access the sql database. Ruby can easily interface c code. So why not use the refdb code as a "library" for doing all the semantic stuff like parsing RIS and scanning for keywords? So we will not get two projects running out of sync, since they reuse the same code. If the database structure changes I need to redo some of the stuff, but that should not be an issue too big. Since most of the database is generated by rails, this must be regenerated the fixes that have to be done should not be too complex. If these changes are too big, I am in doubt that the protocols and datastructures between the client and server will stay as they are. >> - you'll have to change your code whenever I do. I'm just compiling a >> proposal >> how to extend the RIS model to make it easier to implement and >> understand. This >> will require thorough changes to the SQL database schemas. > > What changes are you contemplating to the SQL model Markus? > > FWIW, I've come to the conclusion that reference data really comes > down to these primary entities: Reference (anything citable), > Collection (periodicals, archival collections, series), Event > (workshops, conferences, etc.), and Contributor (authors, publishers, > translator, etc.). I still wonder, how the ris model depends on the sql structure. I like the db structure of refdb and do not see the necessity to change it. If extensions are needed that should not break the existing structure. Furthermore, is it important to be backward compatible since existing databases should be accessible by future versions of refdb. Thanks for the good and interesting points in this discussion. Regards, Sebastian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X