On Tue, Apr 21, 2009 at 3:37 PM, Bèrto ëd Sèra <berto.d.sera at gmail.com>wrote:

> Hi!
>
> The reason I make so many enquiries about long objects (as you probably
> guessed) is that I need them for a project. I did a number of experiments
> with more traditional interfaces and they mostly failed to retrieve an IN
> OUT TEXT parameter from an SP. Functions weren't used because functions do
> not allow for transaction management (at least in MySQL) and I'm sending the
> DB a list of abstract XML commands that are to be encapsulated into a single
> transaction.
>
> I can obviously use tricks (like generating a numeric index for a later
> SELECT of the value) but this all has a performance fee I'd rather not pay.
> Most of the bad benchmarks applications get from using RDBMS come from the
> huge number of interactions they need with the DB, so I'm really trying hard
> to make it all in one shot. The idea is to send in a potentially huge XML
> string that contains all the needed operations, parse it and process it with
> a local stored procedure and return a result in a single go.
>
> To make an insulation layer I eventually resorted to python-twisted, so
> that GUIs do not even know they are talking to a RDBMS and if tomorrow we
> want to switch technology we can do it directly from the python daemon. This
> is a vital need since the daemon doesn't only talk to SmallTalk, but also to
> legacy systems for repository updates and there are other developing parties
> who are willing to develop their own non-SmallTalk UIs. If we end up with
> loads of connection strings all over this structure we are going to be
> paralyzed pretty soon, let alone the problem of having passwords stored in
> clear in way too many places.
>
> The problem I usually saw with IN OUT parms is that you simply don't know
> how long the object is and most retrieval strategies need exactly that to
> fecth the content. There must be other ways, since internally SPs exchange
> these parms pretty well, but C based APIs (like PHP) usually fail at this
> task.
>

Ok. Now I get it. The problem is that perhaps it isn't openDBX who doesn't
support this, but the client library itself (MySQL in this case).



>
> I'm currently porting my system to gentoo, so I'll be fairly busy in the
> next 3-4 days (first gentoo install! so maybe I'm too optimistic on timing),
> but after that I'll give OpenDBX a try and report the results.
>


Yes please. And let me know. I sent an email to Norbert asking for some tips
and cc to you

Cheers,

Mariano



>
>
> Berto
>
> 2009/4/21 Mariano Martinez Peck <marianopeck at gmail.com>
>
>>
>>
>> On Tue, Apr 21, 2009 at 2:04 AM, Bèrto ëd Sèra <berto.d.sera at gmail.com>wrote:
>>
>>> Hi!
>>>
>>> Multistatement is okay, that's just to make sure the API knows what to
>>> do. But beware that retrieving TEXT/BLOB fields as parameters sometimes may
>>> be far from easy, due to the fact that you have no idea of the actual
>>> lenght. PHP basically cannot do it, so I wonder if openDBX can. Let me know.
>>>
>>
>> As I can figure out from your email, you know far much more than I in SP.
>> However, I think we are mixing two things:
>>
>> 1) SP support: This SHOULD be as I told you: enableMultistatement and just
>> query the resutls. But, it was never tested so we don't know if it works. I
>> don't know how input and oput variables should be managed. I will give it a
>> try.
>>
>> 2) Long fields support: OpenDBX support large objects (TEXT/BLOC...). We
>> (right now) do not. This is also planned. You can see it here:
>> http://wiki.squeak.org/squeak/6106
>> We have to map from string (openDBX) to objects (squeak). You can read
>> here: http://wiki.squeak.org/squeak/6075 how we do this.
>>
>> There it says:
>>
>> "Large objects like CLOB, NCLOB and BLOB are not still supported. However,
>> this is actually not true. OpenDBX has several functions to use a RDBMS.
>> And, it also has another functions to specially manage large objects. But
>> OpenDBX doesn't ALWAYS use those special functions for large objects. It
>> depends on the backend. Some backends need to use those functions, and with
>> others you can just use the standard functions. So, what SqueakDBX actually
>> doesn't support right now are those special functions for large objects.
>> Thus, it doesn't support large objects for the backends that need the
>> special functions. For more information, see
>> http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/1.2.
>> Example: If you see DBXPlatform #createDataTypesMap you will see that CLOB
>> is not supported. But for Sqlite3 you can use the normal functions, so,
>> actually squeakDBX supports that. DBXSqlitePlatform overrides that method
>> and map a CLOB to a String.
>> "
>>
>>
>> Once we get 1) and 2) working, I think we can have the mix of them: SP
>> that use large objects.
>>
>> What do you think ?
>>
>>
>>
>>
>>>
>>> Berto
>>>
>>> 2009/4/21 Mariano Martinez Peck <marianopeck at gmail.com>
>>>
>>>
>>>>
>>>> On Mon, Apr 20, 2009 at 7:25 PM, Bèrto ëd Sèra <berto.d.sera at gmail.com>wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Compliments! FMI, is there any support for stored procedures, stored
>>>>> functions and IN OUT parameter passing with MySQL 5.1?
>>>>>
>>>>
>>>> Thanks! More or less. At least, it is not tested. However, as you can
>>>> see in: http://wiki.squeak.org/squeak/6106 we plan to do it in a
>>>> future.
>>>>
>>>> When I asked Norbert (openDBX author) about openDBX store procedure
>>>> support, he told me "You have to enable the multi-statement option and
>>>> retrieve all result sets using odbx_result. ". This, in SqueakDBX means:
>>>> DBXConnection #enableMultiStatements and then do #execute: aSQLString.
>>>>
>>>> I guess in this case aSQLString can be the call string to SP, but I
>>>> really don't know.
>>>>
>>>> So, perhaps we do support SP but we don't know it. Is just a matter of
>>>> testing. If you want I can google and see how to create a simple SP and see
>>>> If I can call it and retrieve the results.
>>>>
>>>> Cheers,
>>>>
>>>> Mariano
>>>>
>>>>
>>>>> Thanks
>>>>> Berto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ==============================
>>> Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole
>>> les droits du peuple, l'insurrection est, pour le peuple et pour chaque
>>> portion du peuple, le plus sacré des droits et le plus indispensable des
>>> devoirs.
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> ==============================
> Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole
> les droits du peuple, l'insurrection est, pour le peuple et pour chaque
> portion du peuple, le plus sacré des droits et le plus indispensable des
> devoirs.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090421/26417797/attachment.htm