Re: Need: Better ORM tools/alternatives

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need: Better ORM tools/alternatives

Esteban A. Maringolo
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.

Regards!


Esteban A. Maringolo

ps: My previous response (below) didn't get to the mailing list (bummer!)

2014-02-28 10:13 GMT-03:00 Esteban A. Maringolo <[hidden email]>:

> 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.

_______________________________________________
Pharo-business mailing list
[hidden email]
http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need: Better ORM tools/alternatives

Stephan Eggermont

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.

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.

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.

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.

Stephan Eggermont
Sensus, systems that make sense
www.legacycode.nl







_______________________________________________
Pharo-business mailing list
[hidden email]
http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: where can I learn about CI

Emilio Oca-3
Hi Stephan

Where can I find a tutorial or documentation about this.
I would like to replicate some of that at my work.
Could it be a link to this information on the parho.org web site?

Best.

Emilio


> 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.
>
> 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.


_______________________________________________
Pharo-business mailing list
[hidden email]
http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need: Better ORM tools/alternatives

Esteban A. Maringolo
In reply to this post by Stephan Eggermont
Has any advance been made on this topic?

Regards!

Esteban A. Maringolo


2014-04-10 17:52 GMT-03:00 Esteban A. Maringolo <[hidden email]>:

> 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

_______________________________________________
Pharo-business mailing list
[hidden email]
http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
Loading...