Thread: [Modeling-users] Request for specific adaptors?
Status: Abandoned
Brought to you by:
sbigaret
Menu
▾
▴
modeling-users
|
From: Sebastien B. <sbi...@us...> - 2003-05-31 17:04:03
|
I have the feeling that a request for a specific adaptor was once made here, but I cannot find it again in the archives. Maybe Oracle, or Firebird? BTW if you have a oracle server at hand you can experiment with, and if you have some time testing an adaptor for oracle we could work together to make this happen; I cannot make this on my own: downloading 1.5Gb oracle for linux is far beyond my patience and bandwidth :/ -- S=E9bastien. |
|
From: Mario R. <ma...@ru...> - 2003-05-31 17:48:33
|
I have recently felt that an adaptor to a non-relational db server would be very nice -- useful for simple applications (and installations of)=20 and/or quick prototyping, but will allow that the same application be easily=20 "scaled-up" to a relational server (with no changes to the data model). This does not equate to simple object persistence (e.g. any of several such schemes available, from pickle to zodb, etc.). It is also not about performance ;-!. It is about giving a very high-level separation between the application objects, and the back-end, that will also allow=20 switching between SQL and non-SQL storage. I am in particular thinking of something like bsddb, with string values (rows) that are simply=20 repr(dict). Then searching and filtering can still be achieved without modifying any client code (albeit very inefficiently!). The advantage is that small applications that do not do so much searching and filtering do not suffer very much, and they can be installed a lot simpler (requiring only to make sure to have write access to some directory, as opposed to setting up an sql server). But, the power of the model is still at hand, on which the application can build... mario > I have the feeling that a request for a specific adaptor was once=20 > made > here, but I cannot find it again in the archives. Maybe Oracle, or > Firebird? > > BTW if you have a oracle server at hand you can experiment with, and = if > you have some time testing an adaptor for oracle we could work = together > to make this happen; I cannot make this on my own: downloading 1.5Gb > oracle for linux is far beyond my patience and bandwidth :/ > > -- S=E9bastien. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Modeling-users mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modeling-users |
|
From: Soaf <so...@la...> - 2003-06-01 23:42:33
|
> I have recently felt that an adaptor to a non-relational db server would > be very nice -- useful for simple applications (and installations of) > and/or > quick prototyping, but will allow that the same application be easily > "scaled-up" > to a relational server (with no changes to the data model). > This does not equate to simple object persistence (e.g. any of several > such schemes available, from pickle to zodb, etc.). It is also not about > performance ;-!. It is about giving a very high-level separation between > the application objects, and the back-end, that will also allow > switching > between SQL and non-SQL storage. I am in particular thinking of > something like bsddb, with string values (rows) that are simply > repr(dict). > Then searching and filtering can still be achieved without modifying > any client code (albeit very inefficiently!). The advantage is that > small applications that do not do so much searching and filtering > do not suffer very much, and they can be installed a lot simpler > (requiring only to make sure to have write access to some directory, > as opposed to setting up an sql server). But, the power of the model > is still at hand, on which the application can build... > > mario This is a good idea, since I usually don't use modeling for small stuff as i need to use a big SQL server w/. PySQLITE is really a great stuff i think my next dev about modeling will use this. Perhaps we should look at gadfly ? (or ZODB + SQL ) |
|
From: Mario R. <ma...@ru...> - 2003-06-06 09:17:37
|
>> I have recently felt that an adaptor to a non-relational db server=20 >> would >> be very nice -- useful for simple applications (and installations of) >> and/or >> quick prototyping, but will allow that the same application be easily >> "scaled-up" >> to a relational server (with no changes to the data model). >> This does not equate to simple object persistence (e.g. any of = several >> such schemes available, from pickle to zodb, etc.). It is also not=20 >> about >> performance ;-!. It is about giving a very high-level separation=20 >> between >> the application objects, and the back-end, that will also allow >> switching >> between SQL and non-SQL storage. I am in particular thinking of >> something like bsddb, with string values (rows) that are simply >> repr(dict). >> Then searching and filtering can still be achieved without modifying >> any client code (albeit very inefficiently!). The advantage is that >> small applications that do not do so much searching and filtering >> do not suffer very much, and they can be installed a lot simpler >> (requiring only to make sure to have write access to some directory, >> as opposed to setting up an sql server). But, the power of the model >> is still at hand, on which the application can build... >> >> mario > > > This is a good idea, since I usually don't use modeling for small = stuff > as i need to use a big SQL server w/. PySQLITE is really a great stuff > i think my next dev about modeling will use this. > > Perhaps we should look at gadfly ? (or ZODB + SQL ) Yes, in fact SQLite or Gadfly are certainly better choices for the cases I described... S=E9bastien, do you think you will integrate the SQLite adapter you had announced some time ago, for 0.9? Cheers, mario |
|
From: <so...@la...> - 2003-06-06 09:30:29
|
On Fri, Jun 06, 2003 at 11:17:35AM +0200, Mario Ruggier wrote: > > > >Perhaps we should look at gadfly ? (or ZODB + SQL ) >=20 > Yes, in fact SQLite or Gadfly are certainly better choices for the > cases I described... >=20 > S=E9bastien, do you think you will integrate the SQLite adapter > you had announced some time ago, for 0.9? If fact the only problem for me is that all of this requires some special DBApi adapter in C on the server. As i host some website on a friend box, this avoid me to use some C adapter (same issue on python-hosting.com for example) . That's why gadfly is=20 interesting no ?=20 bye Bye .:)=20 |
|
From: Sebastien B. <sbi...@us...> - 2003-06-10 16:05:10
|
Hi, Mario> Yes, in fact SQLite or Gadfly are certainly better choices for the Mario> cases I described... Mario>=20 Mario> S=E9bastien, do you think you will integrate the SQLite adapter Mario> you had announced some time ago, for 0.9? Yes, it will be integrated in 0.9 (and possibly before). Soif> If fact the only problem for me is that all of this requires some Soif> special DBApi adapter in C on the server. As i host some website Soif> on a friend box, this avoid me to use some C adapter (same issue Soif> on python-hosting.com for example) . That's why gadfly is=20 Soif> interesting no ?=20 Well, in a way you're right, however it lacks a lot of functionalities, for example: no NULL, no Date, Time, and Interval data types, no LIKE string predicate. (cf. gadfly.sf.net/sql.html) Plus another thing I do not understand (or do I?) << Cursor based updates and deletes (justification: if you really need them the db design is flawed, and it's possible to use python instead). >> --> does it really mean you cannot INSERT/UPDATE on a cursor?? BTW, making a gadfly adaptor means that every non-supported feature should be detected and reported as such; I don't want to do this by now but if anyone feels like starting it I'll help for sure. You're also mentioning python-hosting.com: "plan 1" lets you use firebird, I guess it's probably a better choice there. If there is interest for that one I'll make the effort. Cheers, -- S=E9bastien. |
|
From: Sebastien B. <sbi...@us...> - 2003-06-12 00:21:45
|
Sebastien Bigaret <sbi...@us...> wrote: > Mario> S=E9bastien, do you think you will integrate the SQLite adapter > Mario> you had announced some time ago, for 0.9? >=20 > Yes, it will be integrated in 0.9 (and possibly before). The new adaptor layer for SQLite has been added to cvs today, and will participate in the next release. -- S=E9bastien. |
|
From: Mario R. <ma...@ru...> - 2003-06-17 18:05:30
|
> > Sebastien Bigaret <sbi...@us...> wrote: >> Mario> S=E9bastien, do you think you will integrate the SQLite = adapter >> Mario> you had announced some time ago, for 0.9? >> >> Yes, it will be integrated in 0.9 (and possibly before). > > The new adaptor layer for SQLite has been added to cvs today, and=20 > will > participate in the next release. > > -- S=E9bastien. Great, thanks. Sorry been so virtual lately... Hope to try this one out soon. mario |
×
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