[ANN] New Pharo Glorp version and Book chapter

Hello all,

During the first part of the year, and sponsored by the Pharo
Consortium, I started a new port of Glorp, the Object-Relational
mapper, based on the latest version available in VW 8.0.1.

This latest port was done from scratch in Pharo and brings features
and bugfixes that were accumulated in the VW port during more than 5
years (previous Pharo port) and weren't available until now; and it
uses the Garage database drivers (but not limited to them).

During the last couple of months, and also by request of the
Consortium, I wrote a chapter for one of the Pharo books describing
Glorp as much as possible, with tutorials and key concepts. The
chapter ended up being the longest in text and pages of all written;
the domain is so broad and deep that I'm considering taking it to a
whole book, who knows...

The book is available at
<https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Glorp/Glorp.pdf>,
and I will welcome suggestions and corrections as pull requests to
<https://github.com/SquareBracketAssociates/PharoInProgress>

The Glorp repository is the same as the previous one
(http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
Metacello configs will load the previous version for Pharo 4 and the
new version for Pharo 5. For the foreseeable future I'll continue
maintaining Glorp, but the code is MIT and I'm open to contributions
(I'll set up a Github repo in the next days).

Also I've been running production software based on Glorp for a few
years now, so my experience with it cover most of its features and
usage patterns, so if you have particular questions not covered by the
book chapter or any other material feel free to ask me, this mailing
list or to the Glorp mailing list at <[hidden email]>.

Best regards!

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Excellent Esteban.
Thanks a lot !!!!



Ing. Pablo Digonzelli
Software Solutions
IP-Solutiones SRL
Dividato SA
25 de Mayo 521
San Miguel de Tucumán
Email: [hidden email]
[hidden email]
Cel: 5493815982714

----- Mensaje original -----
De: "Esteban A. Maringolo" <[hidden email]>
Para: "Pharo users" <[hidden email]>, "GLORP Mailing List" <[hidden email]>
Enviados: Domingo, 29 de Mayo 2016 15:27:17
Asunto: [ANN] New Pharo Glorp version and Book chapter

Hello all,

During the first part of the year, and sponsored by the Pharo
Consortium, I started a new port of Glorp, the Object-Relational
mapper, based on the latest version available in VW 8.0.1.

This latest port was done from scratch in Pharo and brings features
and bugfixes that were accumulated in the VW port during more than 5
years (previous Pharo port) and weren't available until now; and it
uses the Garage database drivers (but not limited to them).

During the last couple of months, and also by request of the
Consortium, I wrote a chapter for one of the Pharo books describing
Glorp as much as possible, with tutorials and key concepts. The
chapter ended up being the longest in text and pages of all written;
the domain is so broad and deep that I'm considering taking it to a
whole book, who knows...

The book is available at
<https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Glorp/Glorp.pdf>,
and I will welcome suggestions and corrections as pull requests to
<https://github.com/SquareBracketAssociates/PharoInProgress>

The Glorp repository is the same as the previous one
(http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
Metacello configs will load the previous version for Pharo 4 and the
new version for Pharo 5. For the foreseeable future I'll continue
maintaining Glorp, but the code is MIT and I'm open to contributions
(I'll set up a Github repo in the next days).

Also I've been running production software based on Glorp for a few
years now, so my experience with it cover most of its features and
usage patterns, so if you have particular questions not covered by the
book chapter or any other material feel free to ask me, this mailing
list or to the Glorp mailing list at <[hidden email]>.

Best regards!

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Thanks all. There were several people that helped me along this
endeavor and I thank again the Pharo Consortium for pushing this.

2016-05-30 5:04 GMT-03:00 Denis Kudriashov <[hidden email]>:
> Good job, Esteban.
> Now we need good Garage drivers for databases which not lock image. Does
> anyone plan to work on Oracle and SQLServer backends?

The Garage drivers got hurt by the changes in the FFI API (UFFI), but
there are some people working on getting them back for Pharo 5. This
is really important, and for those RDBMS you mention in particular,
according to a survey [1] I did at the end of last year. We'll get
there.

Those willing to discuss issues or collaborate on these topics can
always use this mailing list, but there is an active community of
developers in the Pharo Project Slack team, we have one channel
dedicated to database discussion [2].

Also, I copied the latest commit from the SmalltalkHub repo to GitHub
in order to use its issue tracker [3] for bug reporting.

Regards!

[1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f640878db
[2] https://pharoproject.slack.com/messages/databases/
[3] https://github.com/DBXTalk/Glorp/issues


Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Tried downloading the new Garage/GLORP code and am getting the following error:

'Could not access http://smalltalkhub.com/mc/Garage/GarageGlorp/main/: ZnHttpUnsuccessful: 404 Not Found'

Hi Brad,

How are you trying to load it?

That repository URL doesn't seems right to me, because Garage and
Glorp are part of the DBXTalk user.

Try with this:

Metacello new
        smalltalkhubUser: 'DBXTalk' project: 'Garage';
        configuration: 'GarageGlorp';
        version: #stable;
        load.

Regards!

Esteban A. Maringolo


2016-05-31 14:49 GMT-03:00 Brad Selfridge <[hidden email]>:
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

That seems to work.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/148cedfa-46a8-4ad2-81f1-e3d563f05d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJsHSjXrbB8_BKFczi15RgHqx%3DR3OttJaoPwRdH%2BZCbjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAGWHZ9_1y3Q949fDpx6BP%2BtF6%2BQuYc6evYXRFYqtzupw4yVsTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Your words remembered me of the trouble I also had/have porting from Pharo to VW and back (Roassal, Seaside, ChartJS).

Having e.g. Seaside based on Grease makes porting easier, though I also found missing links. But I didn't know where to "apply" for or propose extensions to Grease, or how to streamline packages on both sides. And I also found projects that each define their own platform compatibility layer.

Wouldn't that be a good candidate for the ESUG Camp Smalltalk? I would really welcome a project that makes porting back and forth between Smalltalk dialects easier.

Thomas

PS: I agree with you that VW is not the most open oriented tool from the vendor side, but that doesn't mean that its users are the same.

Joachim,

The trunk codebase is in VisualWorks mostly because its source control system (Store) is built on top of it.

I did the latest port of Glorp to Pharo around 3 years ago, and the process albeit semi automatic, required a lot of manual work, and there is no documentation, and VisualWorks doesn't have many "bridges" to reach out to other dialects. Now there is the SETT tool that allows to port Store packages to Pharo, that might help, but other things remain to be solved.

Glorp codebase has its own dialect checks but it is not even close to how it is achieved in Seaside, since a good part is done by conditional checks of the style #isVisualWorks, #isPharo, etc.

As for the RDBMS it is a matter of uses cases, and even when Glorp can adapt into many use cases, my impression is that ORM these days have an ActiveRecord style for 80% of the cases, so the remaining 20% where Glorp could shine is not used much.

In Pharo there is the additional problem of not having a single database layer, and among the specific drivers none is for some serious corporate databases support (it is, Oracle, MSSQL and DB2), and only PostgreSQL, MySQL and SQLite are used in the wild, as far as I know. 

PGSQL has improved with P3, and SQLite driver is great, but still not the use case where you could map anything in a corporate database with a schema not designed to be used as a ORM to a Smalltalk object.

What could be done?

Well... I like RDBMS, and ORMs, but I find defining all the tables, models and mappings quite burdening, that with schema migrations and similar stuff makes me thing more than once about choosing it as my primary solution. So simplification in this realm could help its adoption.

In my dream I'd like to "fork" from the VW codebase and refactor it mercilessly to use Grease as a dialect neutral layer, refactor some parts of the code, and turn it into the canonical implementation that is not dependant of VW/Store needs.

This is a pending project I had right after I finished porting it to Pharo, but since it requires community coordination, and it is something I can't afford now, since I wont profit directly from and even if I would I don't have the time to do it.

Why a fork? Because VW is not the most "community" or "open" oriented dialect these days, nor has showed any interest or open participation in the building of such values, the Seaside port, again, is such an example.

Whether it is called Glorp or something else at the end is irrelevant, I'd keep the name because it shows respect for its heritage.

Regards,

Esteban A. Maringolo

On Wed, May 22, 2019 at 3:12 AM jtuchel <[hidden email]> wrote:

Coming back to this thread, because I just recently found out how important currency on Glorp versions can be...

Is there any documentation on how the port was done? I mean, is there anything that people who'd like to port newer versions of Glorp to Pharo or any other dialect can start from (other than scratch)?

As a mere dummy using Glorp it seems like it is hard to get new versions of Glorp ported over to other dialects, it would be done regularly otherwise, right?

I am not really active in the Pharo or VW ecosystems due to lack of time, but I do follow this group in the hopes of learning something new for my day job with Glorp. It seems to me that Glorp ports to Pharo and VAST and maybe even Squeak are hard to do but desperately looked for...

I also have the feeling that RDB and Smalltalk these days is a very "complicated" relationship. Glorp is the Gold standard, but it seems it is only really available on one Smalltalk platform. I wonder what could be done to change that.

Joachim
 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/148cedfa-46a8-4ad2-81f1-e3d563f05d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJsHSjXrbB8_BKFczi15RgHqx%3DR3OttJaoPwRdH%2BZCbjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/5ad5fc2f-b40d-a3f1-25c6-e4c1b9414ac6%40porabo.ch.
For more options, visit https://groups.google.com/d/optout.

Hi Estaban,

I did a bit of work on Glorp before and during eight or nine years as the maintainer of Store for Cincom. I helped write an VAST-Oracle ORM layer for a banking app, and I've played around with Ruby on Rails and other ORM related things. Here are some comments on what you're saying here:

Joachim,

The trunk codebase is in VisualWorks mostly because its source control system (Store) is built on top of it.

I did the latest port of Glorp to Pharo around 3 years ago, and the process albeit semi automatic, required a lot of manual work, and there is no documentation, and VisualWorks doesn't have many "bridges" to reach out to other dialects. Now there is the SETT tool that allows to port Store packages to Pharo, that might help, but other things remain to be solved.

Glorp codebase has its own dialect checks but it is not even close to how it is achieved in Seaside, since a good part is done by conditional checks of the style #isVisualWorks, #isPharo, etc.

Glorp has the Dialect class which hides some of the differences, but other than that, you're right.

As for the RDBMS it is a matter of uses cases, and even when Glorp can adapt into many use cases, my impression is that ORM these days have an ActiveRecord style for 80% of the cases, so the remaining 20% where Glorp could shine is not used much.

ActiveRecord has serious limitations. It may be that 80% of the people talking about what they're doing are using it, but one of the reasons there are so many ORM frameworks is because people hit the wall in production applications and have to do something else.

In Pharo there is the additional problem of not having a single database layer, and among the specific drivers none is for some serious corporate databases support (it is, Oracle, MSSQL and DB2), and only PostgreSQL, MySQL and SQLite are used in the wild, as far as I know. 

PGSQL has improved with P3, and SQLite driver is great, but still not the use case where you could map anything in a corporate database with a schema not designed to be used as a ORM to a Smalltalk object.

The lack of a single database driver interface in Pharo is, in my mind, the most significant lack. With a single API, building an Active Record or other ORM on top of the driver layer is much easier. Being database independent is a selling point.

What could be done?

Well... I like RDBMS, and ORMs, but I find defining all the tables, models and mappings quite burdening, that with schema migrations and similar stuff makes me thing more than once about choosing it as my primary solution. So simplification in this realm could help its adoption.

This *is* what's involved in talking to a production database.

In my dream I'd like to "fork" from the VW codebase and refactor it mercilessly to use Grease as a dialect neutral layer, refactor some parts of the code, and turn it into the canonical implementation that is not dependant of VW/Store needs.

Store is nothing special in terms of a database application. For the most part, it's queries aren't special or different than what you'd need in any other real production business application. But it is a production application used every day at Cincom and all of Cincom's customers. Cincom's code base resides in Oracle, PostgreSQL and SQL Server repositories using the same StoreBase bundle of code. There are a few database-specific things for Store outside that, but they all use the same version of Glorp. The current version of Glorp in VW likely doesn't have the problem that Joachim encountered, because I stumbled upon the same problem, maybe 3 years ago, and Niall Ross fixed it and then built tests. A canonical version of a framework that isn't used by serious applications that people's work depends on every day is likely to be a toy.

I understand your frustration with lack of documentation, lack of tools to build schemas, support for schema migration, etc, but forking doesn't add those things, and they will likely still be missing. Why fork before trying to develop a standard database driver layer for Pharo. Without support for databases used in the corporate world like Oracle, MSSQL and possibly DB2, what does a Glorp fork buy you?

This is a pending project I had right after I finished porting it to Pharo, but since it requires community coordination, and it is something I can't afford now, since I wont profit directly from and even if I would I don't have the time to do it.

Why a fork? Because VW is not the most "community" or "open" oriented dialect these days, nor has showed any interest or open participation in the building of such values, the Seaside port, again, is such an example.

Whether it is called Glorp or something else at the end is irrelevant, I'd keep the name because it shows respect for its heritage.

Having said what I said above, thank you for all the work you put into the Pharo port and the documentation. I appreciate both the work and your feelings about how things could be much better in the code and in the community.

Regards,

Tom Robinson

Regards,

Esteban A. Maringolo

On Wed, May 22, 2019 at 3:12 AM jtuchel <[hidden email]> wrote:

Coming back to this thread, because I just recently found out how important currency on Glorp versions can be...

Is there any documentation on how the port was done? I mean, is there anything that people who'd like to port newer versions of Glorp to Pharo or any other dialect can start from (other than scratch)?

As a mere dummy using Glorp it seems like it is hard to get new versions of Glorp ported over to other dialects, it would be done regularly otherwise, right?

I am not really active in the Pharo or VW ecosystems due to lack of time, but I do follow this group in the hopes of learning something new for my day job with Glorp. It seems to me that Glorp ports to Pharo and VAST and maybe even Squeak are hard to do but desperately looked for...

I also have the feeling that RDB and Smalltalk these days is a very "complicated" relationship. Glorp is the Gold standard, but it seems it is only really available on one Smalltalk platform. I wonder what could be done to change that.

Joachim
 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/148cedfa-46a8-4ad2-81f1-e3d563f05d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJsHSjXrbB8_BKFczi15RgHqx%3DR3OttJaoPwRdH%2BZCbjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/6ee1e54a-a670-44ac-5241-101ba2ac2794%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Hi Tom, all,

Thanks for your detailed answer.


On Thu, May 23, 2019 at 12:37 AM Tom Robinson <[hidden email]> wrote:
>
> Hi Estaban,
>
> I did a bit of work on Glorp before and during eight or nine years as the maintainer of Store for Cincom. I helped write an VAST-Oracle ORM layer for a banking app, and I've played around with Ruby on Rails and other ORM related things. Here are some comments on what you're saying here:
>

I've read your name a lot close to Glorp things ;-)



> As for the RDBMS it is a matter of uses cases, and even when Glorp can adapt into many use cases, my impression is that ORM these days have an ActiveRecord style for 80% of the cases, so the remaining 20% where Glorp could shine is not used much.
>
> ActiveRecord has serious limitations. It may be that 80% of the people talking about what they're doing are using it, but one of the reasons there are so many ORM frameworks is because people hit the wall in production applications and have to do something else.

I agree, I worked with enterprise databases, or a Smalltalk system
that had to pull "data" (then objects) from third party databases, and
I know how hard this could be, and how impossible it is to do with
pure ActiveRecord approaches.

Also, good ORM's can hit limits, and stuff like jOOQ
(https://jooq.org) is powerful in some cases, and Glorp has the
building blocks to build something similar.


> The lack of a single database driver interface in Pharo is, in my mind, the most significant lack.
> With a single API, building an Active Record or other ORM on top of the driver layer is much easier.
> Being database independent is a selling point.

I haven't worked with single API except for Perl::DBI (circa 2002) and
Dolphin Smalltalk DB connection classes that were built around ODBC.

But you normally don't mix several databases, so once you have the
Glorp adaptor, everything just follows.
I'm aware that some ORMs these days allow you to have different tables
in different databases, so the analogous to a DescriptorSystem also
specifies at which database this must be written, so one table could
be in an OracleDB and the other SQLite.


> Well... I like RDBMS, and ORMs, but I find defining all the tables, models and mappings quite burdening, that with schema migrations and similar stuff makes me thing more than once about choosing it as my primary solution. So simplification in this realm could help its adoption.
>
> This *is* what's involved in talking to a production database.

I know, but more tools to easily scaffold a simple model are needed.
Of course, once you get yourself trained you build your own tools for
this, my abstract DescriptorSystem has helper methods to build models,
mappings and tables that share common attributes. But still, solving
this part is a bigger selling point than to adapt to any database
schema.

> In my dream I'd like to "fork" from the VW codebase and refactor it mercilessly to use Grease as a dialect neutral layer, refactor some parts of the code, and turn it into the canonical implementation that is not dependant of VW/Store needs.
>
> Store is nothing special in terms of a database application. For the most part, it's queries aren't special or different than what you'd need in any other real production business application. But it is a production application used every day at Cincom and all of Cincom's customers. Cincom's code base resides in Oracle, PostgreSQL and SQL Server repositories using the same StoreBase bundle of code. There are a few database-specific things for Store outside that, but they all use the same version of Glorp. The current version of Glorp in VW likely doesn't have the problem that Joachim encountered, because I stumbled upon the same problem, maybe 3 years ago, and Niall Ross fixed it and then built tests.

I understand it doesn't, but I have the feeling that Glorp wouldn't be
maintained much if Store didn't depend on it.

As for VisualWorks openness, as was mentioned in other email this is
not a critique to developers using VisualWorks or employees, which are
very supportive even when they don't have any obligation, and do it by
mere solidarity, but the vendor profile is very different from others,
including other commercial vendors.

> A canonical version of a framework that isn't used by serious applications that people's work depends on every day is likely to be a toy.

This is the key. And this is the reason I'm not pursuing the "fork"
path. In 2004 I wrote an ORM framework for a former employer to
replace one they had in place, it was inspired by Glorp, but written
from scratch and I took some decisions to not make it "general
purpose" (although it proved to be very extensible), I named it "ORP"
(it could be LORP, because it was lightweight too :) ).
But other than the historical comment, my point is that it grew and is
still in use today because it is part of a business critical system,
connecting mostly to MSSQL and Oracle databases.

In 2013 I started using Glorp with Pharo for two projects, but in 2016
the two projects were shutdown, and since then I have not used Glorp
for any of my products on a daily basis.

> I understand your frustration with lack of documentation, lack of tools to build schemas, support for schema migration, etc, but forking doesn't add those things, and they will likely still be missing. Why fork before trying to develop a standard database driver layer for Pharo. Without support for databases used in the corporate world like Oracle, MSSQL and possibly DB2, what does a Glorp fork buy you?

My reasoning about the fork is to have a defined, documented and open
upstream process to fix bugs, add changes, using modern practices like
pull-requests or similar.
AFAIU, It is very likely that if somebody from VAST today wants to
contribute something to the Cincom public Repository he will be
forbidden because of some policy restricting competing vendors to do
so. And even if changes come from Pharo, there are several
"compliance" steps to get access.

I've been working with VW and my own Store repository for over a year,
and although I find it old-fashioned in the fact that is DB dependent
(online), etc, the merging tool is great, and "it just works" (which
is really valuable).
But, VAST has Pharo's Tonel format reader/writer while VW's doesn't,
and probably wont until some private party wants to add it. And there
are many "friction points" like that that I'd like to avoid.

> Having said what I said above, thank you for all the work you put into the Pharo port and the documentation.
> I appreciate both the work and your feelings about how things could be much better in the code and in the community.

Thank you again, porting is an order of magnitude (or two) simpler
than writing or maintaining.

And having the original creator of the library in this mailing list is
an invaluable asset.

Best regards,

--
Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJhCLPUnDQRFL8zSKFN1tyXACYGo6xUizX8wUm0n%2BGRhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

As for the RDBMS it is a matter of uses cases, and even when Glorp can adapt into many use cases, my impression is that ORM these days have an ActiveRecord style for 80% of the cases, so the remaining 20% where Glorp could shine is not used much.

Maybe people like the fact that ActiveRecord gives you lots of nice working examples in very little time. But ActiveRecord simply won't work for a lot of existing databases or in combination with all kinds of tricks that RDBMs have to offer...

I wouldn't say that ActiveRecord style is the way to go for 80% of the projects - you either give up a lot of the power of objects or SQL. Both have their places.

ActiveRecord has serious limitations. It may be that 80% of the people talking about what they're doing are using it, but one of the reasons there are so many ORM frameworks is because people hit the wall in production applications and have to do something else.

I agree, I worked with enterprise databases, or a Smalltalk system
that had to pull "data" (then objects) from third party databases, and
I know how hard this could be, and how impossible it is to do with
pure ActiveRecord approaches.

Also, good ORM's can hit limits, and stuff like jOOQ
(https://jooq.org) is powerful in some cases, and Glorp has the
building blocks to build something similar.

The lack of a single database driver interface in Pharo is, in my mind, the most significant lack.
With a single API, building an Active Record or other ORM on top of the driver layer is much easier.
Being database independent is a selling point.

I disagree. The most significant lack is the same desease Smalltalk has suffered from for at least 40 years now: nobody seems to give a f*** about protability. There have been so many approaches to it, but none ever found enough support with the majority of commercial Vendors. I'd like to add a few words about this here but my post would not be allowed in some countries then ;-)

You could sure build layers on top of different DB drivers that fit well with Glorp. And of course Glorp could be adapted to several drivers. This has been done in so many technologies already, I don't buy into any technical argument here.

It is a pity none of the RBD connectors in Pharo ever became an agreed Standard and most of them are a ghost town these days (think openDBX, Garage, and even older approaches). I guess this does not so much be a consequence of technical issues than it is a question of how many or few people in the Pharo Community actually work with RDBs.

I haven't worked with single API except for Perl::DBI (circa 2002) and
Dolphin Smalltalk DB connection classes that were built around ODBC.

I think this is very similar to the database API in VA Smalltalk and I would assume this also applies to VW and OS.

But you normally don't mix several databases, so once you have the
Glorp adaptor, everything just follows.

I agree. The only scenarios in which I've seen the need for several databases in one Application were mostly related to migration of data between Applications and/or databases or systems (AS/400 to Unix etc.).

Well... I like RDBMS, and ORMs, but I find defining all the tables, models and mappings quite burdening, that with schema migrations and similar stuff makes me thing more than once about choosing it as my primary solution. So simplification in this realm could help its adoption.

This *is* what's involved in talking to a production database.

I know, but more tools to easily scaffold a simple model are needed.

AFAIK, Cincom has built such tools on top of Glorp and integrated them with their products. I think it is reasonable to have these tools as seperate commercial products. Nobody keeps anybody from doing the same for any other dialect.

Of course, once you get yourself trained you build your own tools for
this, my abstract DescriptorSystem has helper methods to build models,
mappings and tables that share common attributes. But still, solving
this part is a bigger selling point than to adapt to any database
schema.

In my dream I'd like to "fork" from the VW codebase and refactor it mercilessly to use Grease as a dialect neutral layer, refactor some parts of the code, and turn it into the canonical implementation that is not dependant of VW/Store needs.

hmm. I thought about this as well. forking sounds like a sexy choice if you feel the code is locked in Cincom's repositories and hard to get. On the other hand: if enough people in any of the other dialects had enough interest, time and knowledge to accomplish this, it would've been done already. I must say almost every time I try to dig into Glorp's code, I get lost sooner or later. Maintaining Glorp is not an easy task.

Store is nothing special in terms of a database application. For the most part, it's queries aren't special or different than what you'd need in any other real production business application. But it is a production application used every day at Cincom and all of Cincom's customers. Cincom's code base resides in Oracle, PostgreSQL and SQL Server repositories using the same StoreBase bundle of code. There are a few database-specific things for Store outside that, but they all use the same version of Glorp. The current version of Glorp in VW likely doesn't have the problem that Joachim encountered, because I stumbled upon the same problem, maybe 3 years ago, and Niall Ross fixed it and then built tests.

I understand it doesn't, but I have the feeling that Glorp wouldn't be
maintained much if Store didn't depend on it.

Isn't that wonderful? At least somebody has the money and interest to maintain Glorp! I hope Cincom will continue to use Glorp in their product and fix bugs and develop it further. Because if they don't, there's no ORM I could use.

Let's be honest: if somebody asked you: "I'd love to use Smalltalk (or any of its flavors specifically), but I need an ORM - what can you recommend?" What would you answer?

As for VisualWorks openness, as was mentioned in other email this is
not a critique to developers using VisualWorks or employees, which are
very supportive even when they don't have any obligation, and do it by
mere solidarity, 

My feeling as well. Even though this list is not very crowded, most of the time somebody looks into my problems, be it Alan, Niall, Tom or some Glorp user like you or Maarten

but the vendor profile is very different from others,
including other commercial vendors.

Not sure what you are referring to here?

A canonical version of a framework that isn't used by serious applications that people's work depends on every day is likely to be a toy.

+50

This is the key. And this is the reason I'm not pursuing the "fork"
path. 

I am also very sceptical about forking Glorp.

Especially if the main reason for it is a very common problem: lack of code transportability between dialects. This should be attacked rather than overcoming this problem by forking something.

I understand your frustration with lack of documentation, lack of tools to build schemas, support for schema migration, etc, but forking doesn't add those things, and they will likely still be missing. Why fork before trying to develop a standard database driver layer for Pharo. Without support for databases used in the corporate world like Oracle, MSSQL and possibly DB2, what does a Glorp fork buy you?

My reasoning about the fork is to have a defined, documented and open
upstream process to fix bugs, add changes, using modern practices like
pull-requests or similar.

Well, that is not necessarily something that forking buys you. I know the Pharo community has strong processes and tooling and experience with these things, if anybody can do it, it's tehe Pharo crowd. I am still not sure it should be done, however.

AFAIU, It is very likely that if somebody from VAST today wants to
contribute something to the Cincom public Repository he will be
forbidden because of some policy restricting competing vendors to do
so. And even if changes come from Pharo, there are several
"compliance" steps to get access.

Are you speaking from experience? Are you saying Cincom will not accept code contributions from certain groups or companies? If that was true, wouldn't that be stupidity on steroids? I haven't contributed much code to Glorp in the past, mostly because I am not clever enough to understand the code in many places, but when I did or tried, I was never told they couldn't or wouldn't accept it. Quite the opposite, Niall or Tom (back in the days) would be happy to take a look...

If what you are saying is true, it shines a completely different light on the forking discussion, imo.

I've been working with VW and my own Store repository for over a year,
and although I find it old-fashioned in the fact that is DB dependent
(online), etc, the merging tool is great, and "it just works" (which
is really valuable).
But, VAST has Pharo's Tonel format reader/writer while VW's doesn't,
and probably wont until some private party wants to add it. And there
are many "friction points" like that that I'd like to avoid.

Okay, so this finally gets me back to my initial question: how would a port of a new version work these days? The most obvious questions are:

• Is Glorp still open sourced?
  
• How to export Glorp Code from StORE? Where to?
• How to do the actual porting?
• How to make the process repeatable with newer versions

Another problem is how we'd feed changes and fixes back to Cincom or any other maintainer?

All of these questions aren't new. In fact, we've had the same problems with Seaside, VBRegex, RefactoringBrowser, Smacc, SmallLint and many more over decades now - and they were solved over and over again... Isn't that really sad?

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/34fa535d-1296-8f00-3257-715d1b5b18fe%40objektfabrik.de.
For more options, visit https://groups.google.com/d/optout.

Hi Joachim,

On Thu, May 23, 2019 at 11:31 AM [hidden email]
<[hidden email]> wrote:
>
> Hi all,
>
> isn't it interesting how many people have worked on an ORm because they are so impoartant, but there is only one that is currently  available and more or less maintained in the Smalltalk world?

I never understood this, but it might have to do with the fact that
the largest systems (as in really-large systems) built with Smalltalk
uses/used GemStone/S as database (Kapital, OOCL, etc.).
I don't know the success stories of Glorp, though.

> I've heard people telling me "who needs ORMs these days?" This may apply to greenfield projects, but RDBMs will probably be around for another 40 years or so....

Lindy effect is likely to prove you right on your assertion, however
ORMs, or RDBMs chose the Consistency and Availability pair of the CAP
theorem, and in cloud architectures, Availability and Partition are
the kings.

So it's main use isn't in distributed system, although there are
examples that use RDBMS (StackOverflow.com is one), but the Partition
doesn't come out of the box and requires aditional thinking of the
architecture beforehand, and a hell of a replica setup.

> ActiveRecord has serious limitations. It may be that 80% of the people talking about what they're doing are using it, but one of the reasons there are so many ORM frameworks is because people hit the wall in production applications and have to do something else.

My gut feeling is that even ORM's hit some limitation, and that's why
there are "object oriented" querying tools like jOOQ. Sometimes just
for performance reasons.


> The lack of a single database driver interface in Pharo is, in my mind, the most significant lack.
> With a single API, building an Active Record or other ORM on top of the driver layer is much easier.
> Being database independent is a selling point.

I worked for years in Windows with ODBC, on databases with users
accessing it, from Smalltalk systems, in the hundreds, but Oracle
DBA's were not happy with that, they complained that the native driver
(OCI.dll) was way better and faster than ODBC.  But because we had no
option, we stuck with ODBC. So it seems there is always a reason to go
"native" and discard the portability. I don't know if the same happens
in the JDBC world.

> I disagree. The most significant lack is the same desease Smalltalk has suffered from for at least 40 years now: nobody seems to give a f*** about protability.
> There have been so many approaches to it, but none ever found enough support with the majority of commercial Vendors.
> I'd like to add a few words about this here but my post would not be allowed in some countries then ;-)

There are several types of portability, but I agree that at least
"code" portability should exist.

> You could sure build layers on top of different DB drivers that fit well with Glorp. And of course Glorp could be adapted to several drivers.
> This has been done in so many technologies already, I don't buy into any technical argument here.

Glorp is very flexible in this regard, the database "Driver" (aka
"Adaptor") is pretty easy to write, and the Database Dialect (ORA,
MSSQL, etc) is portable.

>
> It is a pity none of the RBD connectors in Pharo ever became an agreed Standard and most of them are a ghost town these days (think openDBX, Garage, and even older approaches). I guess this does not so much be a consequence of technical issues than it is a question of how many or few people in the Pharo Community actually work with RDBs.

OpenDBX (a library no one ever used for real, IMO), Garage and many
other failed attempt to get a common portability layer came from an
academic/intern approach, not without good intentions, but neither to
"scratch the itch" of some concrete business need to use as a baseline
and/or as benchmark.

> I haven't worked with single API except for Perl::DBI (circa 2002) and
> Dolphin Smalltalk DB connection classes that were built around ODBC.
>
> I think this is very similar to the database API in VA Smalltalk and I would assume this also applies to VW and OS.

Well... I used Oracle and ODBC from VAST (VisualAge back then) and
albeit similar, AFAIR they weren't the same.

> > I know, but more tools to easily scaffold a simple model are needed.
>
> AFAIK, Cincom has built such tools on top of Glorp and integrated them with their products.
> I think it is reasonable to have these tools as seperate commercial products.

Totally.

> Nobody keeps anybody from doing the same for any other dialect.

Nobody seems to need it either. Or are not willing, don't have time to
polish and share it :)


> Okay, so this finally gets me back to my initial question: how would a port of a new version work these days? The most obvious questions are:
>
> Is Glorp still open sourced?

AFAIU, Yes.

> How to export Glorp Code from StORE? Where to?

There are a few "writers" Alan mentioned in another email, but that is
no common format and are outdated as well.

> How to do the actual porting?

I'd like to have a common format that interested Smalltalk dialects
can read/write to to exchange code/fixes, etc.
Tonel is a candidate, I don't know about the "Rowan" thing Dale
Henrichs is working on (I think it uses Tonel too), however Tonel
limited to Pharo's needs, it was not designed to support VW's
namespaces, and probably some particularities of VAST neither.

> How to make the process repeatable with newer versions
> Another problem is how we'd feed changes and fixes back to Cincom or any other maintainer?

There must be a canonical implementation dialect and each dialect to
have a "maintainer", I wouldn't choose Cincom Smalltalk as the
canonical dialect (and hence the "fork") because they don't seem to be
looking forward to build "bridges" to other dialects, they serve their
customers, and seem to serve them well, but the fact that something
like SETT was created by a customer wanting to get code "out" of Store
tells you something.

> All of these questions aren't new. In fact, we've had the same problems with Seaside, VBRegex, RefactoringBrowser,
> Smacc, SmallLint and many more over decades now - and they were solved over and over again...
> Isn't that really sad?

Might be sad, it certainly adds friction, but for "active" projects
where every party wants to benefit that friction is workable (Seaside
is the paramount example).


I don't know if this discussion will lead to something, but I feel
good having it. :)

Best regards,

--
Esteban

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCLp6fMF59RpVDAW1NNcKA-CYn-iZ4e_FT2Yo1JA2NtzOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.