Re: Need: Better ORM tools/alternatives

> 2014-02-27 22:55 GMT-03:00 Aaron Rosenzweig <[hidden email]>:
>>
>> I hear you Esteban.
>>
>> GLORP is also primarily for Postgres, if I remember correctly, which would make it a one trick pony. Regardless, having to manually mess around with mapping files would ruin my day too.
>>
>> Yeah, if I was coming to Pharo/Seaside/Tide for doing SQL stuff... I'd probably stick with WebObjects where I do have nice tools for ORM.
>
> That is what I see as a probable concern for others trying to adopt Pharo.
>
>>
>> I understand, sometimes you just have to talk to a SQL database. The system has already existed for a long time, or other reasons. Going forward I'll probably use WO to talk to those systems and expose a REST or other web service. Something minimal to which I'd either have a front-end app that communicates directly or a Smalltalk middle man. In other words, I'd use a strong ORM environment just enough that I can get and set the data.
>>
>> Some people say, they could never use an object database because there will be other systems that need access to the data. I'd say expose the object database as a REST or other web service. It goes both ways!
>
> To me the OODB vs RDBMS discussion is over. No one wins. But I know
> that RDBMS has its place in the OO world, and for most cases it works
> perfectly.
>
> I evaluated Voyage+MongoDB and other persistence solutions before
> choosing an ORM (again), and the external toolset available for RDBMS
> is enormous.
> And last but not least, the "raw data" is easier to access through a
> SQL prompt than to work with NoSQL alternatives. I trust I can get all
> my data in an understandable format (SQL) and move away from that
> particular RDBMS solution (or even Pharo) anytime I need.
>
> Maybe for complex object models ORM is not a solution, or is a real
> pain in the *ss, but in ~10 years doing commercial software (and
> complex one) with Smalltalk and RBDMS (Oracle and MSSQL) we always
> found a workaround for those edge cases of ORM. And that's why, IMHO,
> big cloud providers still offer hosted/cloud SQL solutions (E.g.:
> Azure, Google App Engine)
>
> Regards!
>
> --
> Esteban.

> run the tests you need (you can just copy the job that is most similar to
> yours and adapt it). Had there been a job for Glorp, we would have
> noticed the naming conflict as soon as it occurred, instead of two months
> later.
>
> To tackle driver problems, you'll probably need to create your own CI
> environment. That will be able to be more similar to your production
> environment.
>
> Pharo depends on the users of packages maintaining their own CI
> jobs, and keeping them green. The users are the only ones who can
> make useful decisions on priorities and how to solve arising problems.
> There are enough people able and willing to help when things are
> not easy to fix.

> Stephan,
>
> 2014-04-10 16:33 GMT-03:00 Stephan Eggermont <[hidden email]>:
>>
>> On 10 apr. 2014, at 17:08, Esteban A. Maringolo <[hidden email]> wrote:
>>
>>> My company has green light to start another small project, and the
>>> current state of the ORM tools (it is: GLORP) is the same as before:
>>> - Outdated version (unknown date of fork from VW's version)
>>> - Not tested in Pharo 3 (which is about to be released)
>>> - Fragemented tools and drivers (which seem to be useful, but docs
>>> point to SqueakSource repositories)
>>>
>>> I don't want to sound dramatic, but for me this is a warning light.
>>
>> Pharo is changing fast. Making sure something works in the latest version
>> is mostly not difficult. Waiting longer to make it work again makes things
>> more difficult, because there are more changes to consider.
>
> It is not criticism, it's just a request/concern sent to the Business
> mailining list; because I consider that RDBMS are more prominent in
> business domains than in any other computing environment.
>
>> Pharo has an excellent infrastructure available to help reduce the amount
>> of work needed to keep things running in the latest version. If you create
>> a Metacello configuration loading all open source packages you need,
>> it is easy to create a CI job on pharo-contribution that will load them and
>> run the tests you need (you can just copy the job that is most similar to
>> yours and adapt it). Had there been a job for Glorp, we would have
>> noticed the naming conflict as soon as it occurred, instead of two months
>> later.
>
> I know a lot can be done and is being done, I'm simply pointing out
> the situation from my standpoint, which doesn't have anything special
> and can shared by others.
>
>
>> To tackle driver problems, you'll probably need to create your own CI
>> environment. That will be able to be more similar to your production
>> environment.
>
> I scripted builds, but don't have CI infraestructure yet.
> But they're for Pharo 2. :)
>
>> Pharo depends on the users of packages maintaining their own CI
>> jobs, and keeping them green. The users are the only ones who can
>> make useful decisions on priorities and how to solve arising problems.
>> There are enough people able and willing to help when things are
>> not easy to fix.
>
> I thought there were other users of GLORP. And I'm sure there are. But
> fewer than I thought.
> I still wonder what do people use for ORM.
>
>> I've had interesting experiences trying to load Pharo code in VW,
>> but given enough time, creating a daily jenkins job that starts a VW-NC,
>> connects to the public store, downloads the latest version of
>> Glorp for VW and exports that replacing the namespaces by
>> a prefix in a Monticello file, should be straightforward, and
>> sounds to me like a useful thing to do.
>
> As far as I've been told, this can't be done in the case of GLORP.
> And many issues were fixed by cherry picking the methods in VW and
> filing them manually into Pharo.
>
> Regards!
>
> Esteban Maringolo