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 glorp-group...@googlegroups.com.
To post to this group, send email to glorp...@googlegroups.com.
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 glorp-group...@googlegroups.com.
To post to this group, send email to glorp...@googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJsHSjXrbB8_BKFczi15RgHqx%3DR3OttJaoPwRdH%2BZCbjA%40mail.gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/CAJMgPCJsHSjXrbB8_BKFczi15RgHqx%3DR3OttJaoPwRdH%2BZCbjA%40mail.gmail.com.
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 <jtu...@objektfabrik.de> 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 glorp-group...@googlegroups.com.
To post to this group, send email to glorp...@googlegroups.com.
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 glorp-group...@googlegroups.com.
To post to this group, send email to glorp...@googlegroups.com.
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.
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,
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:
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