Persistence options

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Persistence options

Torsten Bergmann
Regarding Glorp: how well does the Pharo port work with
non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?

Thx
T.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Reply | Threaded
Open this post in threaded view
|

Re: Persistence options

Mariano Martinez Peck


2012/6/26 Torsten Bergmann <[hidden email]>
Regarding Glorp: how well does the Pharo port work with
non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?

They do all work with OpenDBXDriver. Of course you will need the OpenDBX library and the database client library.
For Glorp, it is working for: Oracle, MySql, PostgreSQL, SQLite, SqlServer and ODBC

See: http://rmod.lille.inria.fr/archives/talks/2012-PharoConf-DBXTalk.pdf
 
Cheers,

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Persistence options

Philippe Marschall-2
On 06/26/2012 12:32 PM, Mariano Martinez Peck wrote:

> 2012/6/26 Torsten Bergmann <[hidden email]>
>
>> Regarding Glorp: how well does the Pharo port work with
>> non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?
>>
>
> They do all work with OpenDBXDriver. Of course you will need the OpenDBX
> library and the database client library.
> For Glorp, it is working for: Oracle, MySql, PostgreSQL, SQLite, SqlServer
> and ODBC

You should probably add that without an mt VM the drivers either block
or poll. This is hardly ideal and not comparable to the "native"
PostgreS and MySQL drivers that use sockets and don't have these issues.

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: Persistence options

Mariano Martinez Peck


On Tue, Jun 26, 2012 at 2:21 PM, Philippe Marschall <[hidden email]> wrote:
On 06/26/2012 12:32 PM, Mariano Martinez Peck wrote:
> 2012/6/26 Torsten Bergmann <[hidden email]>
>
>> Regarding Glorp: how well does the Pharo port work with
>> non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?
>>
>
> They do all work with OpenDBXDriver. Of course you will need the OpenDBX
> library and the database client library.
> For Glorp, it is working for: Oracle, MySql, PostgreSQL, SQLite, SqlServer
> and ODBC

You should probably add that without an mt VM the drivers either block
or poll. This is hardly ideal and not comparable to the "native"
PostgreS and MySQL drivers that use sockets and don't have these issues.


Indeed. But it seems that with our "mini-locks" or busy waiting in the image side is enough for the real existing users.
Nobody actually complained about this limitation.
In fact, in VW, by default, queries are blocking... they are *not* azync unless you explicitly tell it. This is because creating threads also take time and if most of the queries are fast, then it is even better the locking strategy.
 
Cheers
Philippe






--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Persistence options

Philippe Marschall-2
On 06/26/2012 02:26 PM, Mariano Martinez Peck wrote:

> On Tue, Jun 26, 2012 at 2:21 PM, Philippe Marschall <
> [hidden email]> wrote:
>
>> On 06/26/2012 12:32 PM, Mariano Martinez Peck wrote:
>>> 2012/6/26 Torsten Bergmann <[hidden email]>
>>>
>>>> Regarding Glorp: how well does the Pharo port work with
>>>> non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?
>>>>
>>>
>>> They do all work with OpenDBXDriver. Of course you will need the OpenDBX
>>> library and the database client library.
>>> For Glorp, it is working for: Oracle, MySql, PostgreSQL, SQLite,
>> SqlServer
>>> and ODBC
>>
>> You should probably add that without an mt VM the drivers either block
>> or poll. This is hardly ideal and not comparable to the "native"
>> PostgreS and MySQL drivers that use sockets and don't have these issues.
>>
>>
> Indeed. But it seems that with our "mini-locks" or busy waiting in the
> image side is enough for the real existing users.
> Nobody actually complained about this limitation.
> In fact, in VW, by default, queries are blocking... they are *not* azync
> unless you explicitly tell it. This is because creating threads also take
> time and if most of the queries are fast, then it is even better the
> locking strategy.

If it works for you that's great. It's just one of these things that you
want to know up front instead of finding out later.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Persistence options

Mariano Martinez Peck


On Tue, Jun 26, 2012 at 6:20 PM, Philippe Marschall <[hidden email]> wrote:
On 06/26/2012 02:26 PM, Mariano Martinez Peck wrote:
> On Tue, Jun 26, 2012 at 2:21 PM, Philippe Marschall <
> [hidden email]> wrote:
>
>> On 06/26/2012 12:32 PM, Mariano Martinez Peck wrote:
>>> 2012/6/26 Torsten Bergmann <[hidden email]>
>>>
>>>> Regarding Glorp: how well does the Pharo port work with
>>>> non-Postgresql already: MySQL, SQLServer, Oracle, Firebird, ... ?
>>>>
>>>
>>> They do all work with OpenDBXDriver. Of course you will need the OpenDBX
>>> library and the database client library.
>>> For Glorp, it is working for: Oracle, MySql, PostgreSQL, SQLite,
>> SqlServer
>>> and ODBC
>>
>> You should probably add that without an mt VM the drivers either block
>> or poll. This is hardly ideal and not comparable to the "native"
>> PostgreS and MySQL drivers that use sockets and don't have these issues.
>>
>>
> Indeed. But it seems that with our "mini-locks" or busy waiting in the
> image side is enough for the real existing users.
> Nobody actually complained about this limitation.
> In fact, in VW, by default, queries are blocking... they are *not* azync
> unless you explicitly tell it. This is because creating threads also take
> time and if most of the queries are fast, then it is even better the
> locking strategy.

If it works for you that's great. It's just one of these things that you
want to know up front instead of finding out later.


+1



--
Mariano
http://marianopeck.wordpress.com