Is ORM available in Lucee 5 Beta at the moment?

[Tony Junkes]

I thought I remembered seeing the extension available in the Lucee5-Express admin, when it was first released, but now I do not.

I wanted to start throwing some of my apps against the beta as a regular install. Initially upon getting Lucee 5 installed, every site is running normally except the one that uses ORM (for the obvious reason that ORM is not enabled). It was my understanding that ORM was going to be an add-on, which is perfectly fine, but I cannot seem to see it as an option to "switch on".

Am I missing something or is it still in the works?

[Michael Offner]

We have removed the ORM Extension for the moment because people have experienced some problem with it, we first plan to solve this issues.

We hope to release it again this week, we keep you posted...

Micha

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/162a60cb-ef24-4384-b02d-b25048f60c12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tony Junkes]

Thanks, Micha.

[Tony Junkes]

Any updates as to when we might be able to try out the orm extension again?

[Rory Laitila]

This is by the way, one of the things that worries me. What is the user value in having this ORM as an extension? Its not like we are going to have multiple competing ORM implementations for this small community and platform, so why isn't this bundled in the core? The benefit of using Lucee (over virtually any other platform) is it is 'batteries included': it is actually a language + framework. 

Also, the extensions historically have never been top notch and I've had problems with every one I've used over the years. I don't expect them to be kept up to date because they are not considered core. Even though this is beta, here we have a situation now where the broken ORM is simply excluded from the beta release. I think ORM in this day in age is a necessary tooling for many applications: the beta release should be considered bugged, not just the extension.

Why are we making it harder for users, not easier? In the future, I am now going to need to script installation of these once 'core' features, for no benefit whatsoever to my projects. My life is not better by Lucee having fewer features. Maybe it helps development, but that isn't a direct benefit to adoption. From my perspective, I want Lucee to be more feature rich, to make things even easier, to bake in more services for the common use cases. Sure let the engine be extensible when you need to switch it out for corner cases, but the 80% use case is where Lucee shines today. 

[ADK]

I couldn't disagree more. One of the things that excites us about Lucee 5 is this "feature" and ORM is a perfect example of something that we have no interest in so we're glad that the app engine will not necessarily be bogged down with it's superfluous baggage.

The feature will be there if you need it - it may even be a "core, included by default" extension (so we'll end up being the ones scripting a custom install, instead of you!) but the more crap you can stick into extensions, so that the main engine stays lean and mean, the better in my opinion.

[Andrew Penhorwood]

I agree with ADK.  I see no reason to ever use ORM.  If you like it that is fine just don't require me to use it or have it on my server.

Andrew Penhorwood

[Jon Clausen]

I kind of agree with ADK as well, though I use ORM extensively.  The Hibernate ORM implementation is flawed, slow, has terrible error handling, and blows at handling database migrations unless the DB was created by Hibernate in the first place. I like ORM as an extension, if only because it opens the door to another compatible implementation being devised and implemented, which could run “native".  I think omitting it keeps the Lucee core fast, which benefits us all.

My concern is the extension overhead when activating those extensions - as is often seen with modularity in other scripting engines. I’ll leave that concern, though, to the Luce development team and trust that they will design the extension implementation in a way that makes extension handling part of the core, rather than as a “plugin” approach, which incurs a performance hit for every activation.

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f26a15c7-5712-4f90-b1dd-9d4878dfbb18%40googlegroups.com.

[Samuel W. Knowlton]

It seems to me that the Lucee community can either make an arbitrary determination about who uses what based off of who speaks up on this list or they can figure out a means of collecting real data. 

Our company uses CFML and Hibernate exclusively for two large web applications. We have considered dropping CFML in the past for many of the reasons that Lucee exists - we aren't crazy about Adobe's leadership (or absence of it) and uninterested in the direction that they seem to be going. 

So, for us it's a requirement and for you it's not a concern. Do we cancel each other out? Is one of us wrong? I don't think it matters, but the fact that ORM has been broken since Lucee has come out is pushing us either back to Adobe or else away from CF at all. 

For my money, and we do have some money to spend on this kind of thing, I'd rather see improvements made where they're needed than a major feature of CF tossed out the window. For us and our company, ORM is very much a 'core' piece of the server just as much as cfquery is.

[Rory Laitila]

Everyone's reasons are all valid to their ends: "just don't require me to use it or have it on my server" (but we could say this about anything) and "The Hibernate ORM implementation is flawed, slow, has terrible error handling" (there are certainly more elegant ORMs). But I don't agree with the "the main engine stays lean and mean, the better in my opinion". I just don't think it is a sustainable market differentiation for Lucee among the available platform options in the wider market. I think where the minimalist roadmap will take us will be great! (in theory) However the result will be, we will have a minimalist scripting engine which is indistinguishable in its value from other already minimalist and 'pure' languages. I am raising the concern (not unreasonable I think), that the extensions will not be maintained with the normal release cycle. Whether or not Lucee is built from extensions is an implementation detail in one sense, so I am really talking about fully supporting the ORM (and existing functionalities) so that they are considered necessary for every release (which has not been true for extensions, they seem to be second class). 

So it will be a 'good' result for those that want a minimalist engine (which I seriously wonder with no snark, why are you still using this platform if that is what you need, are there not already superior ecosystems?), but I think where Lucee shines is in what it offers for the general web application development use case, and all its attending services.

[Carl Von Stetten]

I'll throw in my two cents.  I have never used ORM, and have no immediate plans to start using it.  I very much like the idea of not having ORM installed at all so that Lucee can run faster and lighter.  As long as the "ORM extension" can be installed by those who need it, is maintained by LAS as a "core" extension (not reliant on 3rd parties to maintain and supported by LAS for bug fixes), and provides comparable performance to anything running in the actual Lucee core - then I think it's a win/win for everyone involved.

If, however, moving ORM to an extension will create a performance penalty for ORM users, than it should be considered very carefully and all of the supporters and sponsors should have a voice in the process.

For me, the bottom line is that I don't want to be penalized for having ORM/Hibernate running all the time when I don't/won't use that functionality.
-Carl V.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com.

[Tony Junkes]

There's some great points and concerns to be had in this discussion.

Seeing as how it's been advertised that the whole purpose of ORM being made as an extension was to help lean out Lucee for those not using it (along with other features), it sounds like everyone is getting what they want out of it. I'm pretty sure that in Lucee 5, if you want ORM, you have to install the ext(?). So everyone who doesn't want it is set from the start.

The issue would ultimately be if ORM as an extension took a performance blow or was just simply not maintained on a similar level to "core" features. It happens to be somewhat of a core feature for me; and has been for years now. In it's current status it's more and more seeming half-assed with the bugs that continue to exist and that's just bs to me this far down the line; crossing from 2 different engines. I don't expect some mass scale priority on it but it seems to be shadowed for a good while now between Railo and Lucee.

ORM in CFML has long had it quarks and I'm sure some of it comes from hibernate directly but I happen to be one of the people who have found it useful and efficient enough to build some large projects with it doing the heavy lifting. Like anything else, you learn to tame it as best you can. In the same breath, I know it's not the tool for every job; like everything in this industry these days.

I just want to see something in regards to ORM and Lucee 5 come to light so I can start testing my apps against it and ultimately help the lot put out a feature that's as rich as possible.

[ADK]

Carl - I agree completely.

There's a big difference between abandoning ORM and segregating it from the core as an extension. The same goes for anything else being pulled out as an extension.

I don't think (and I suppose I could be wrong) that the intention was ever to yank ORM from the core and then just say to the community "have at it if you want to improve upon it, but we're done with it and are just working on the core now!" (perhaps I am wrong here though?)

I think it's about taking a sensible approach to what make more sense being "classified" as an extension so that it can be loaded/unloaded as the individual user sees fit? Again: modular=good, monolithic=bad. But if you want the kitchen sink, YOU can still have it with the extension approach. Win-win, right?

I assume it will be very similar to what the Coldbox team did with version 4: they made Coldbox modules first class citizens and moved their entire framework to a modular architecture. All of the "core modules" that were once in the Coldbox core are still being actively developed and maintained by the Coldbox team.

So, I don't see anybody losing anything here?

In fact - and I think this is a key point - it seems one of Rory's main concerns: "that the extensions will not be maintained with the normal release cycle" is actually an argument in favor of this modular approach. Now - if there are issues that need to be addressed in the ORM extension, they can be done separately and/or on a different stream than that of the Lucee core. Specific ORM issues could now be addressed without waiting for more core point releases. If new ORM versions want to be used that require updated jars (for instance) then that could be done right away rather than waiting for major releases (the only time I believe core jars are allowed to be updated is between majors, right?)

By the way, Adobe has already announced that future versions of ColdFusion would also take on a modular approach. I don't know if that means ORM will be pulled out as a "module" but I think it's as likely as not...

Anyways, those are my thoughts on it...
Andy

[Samuel W. Knowlton]

>> I don't think (and I suppose I could be wrong) that the intention was ever to yank ORM from the >> core and then just say to the community "have at it if you want to improve upon it, but we're done >> with it and are just working on the core now!"

As a strategy, this sounds perfectly reasonable. Unless and until Lucee's ORM implementation somehow comes in inferior in performance to Adobe's, I don't care how I turn it on; so long as I can turn it on and so long as it is maintained, I'm happy.

I guess this conversation would probably be better had as more academic and less sensitive, but it's tough because ORM has been broken since the Lucee 5 beta. Like Tony, I didn't imagine that it would be a top priority, but it's been a while now.

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/VTF4k2sM1MI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/71bac58a-a4af-42c1-bfc7-1a6e0082faac%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Samuel W. Knowlton
Chief Leagueologist
inLeague * s...@inleague.org
http://www.inleague.org
Office: 512.814.8022

[ADK]

Completely understand.

ORM is to you what spreadsheet manipulation is to me for one of our corporate customer's apps... that's why I hacked the the old, abandoned cfspreadsheet extension to work in Lucee!  So I am not without sympathy at all!  :-)

[Geoff Bowers]

The extensions stuff and OSGi in general is an architectural approach, not an effort to marginalise things that go into extensions.  There will certainly be "core" extensions that are not loaded by default, but only as needed.  This gives the engine the ability to be lean, without the excess baggage that say ACF carries by having to load everything regardless of whether or not its used by the application.

Even the Lucee Admin and Lucee Docs that ship with Lucee server will be extensions!  This means that you can ship ephemeral servers that are fully scripted without ever having to have the Admin deployed.  But obviously a majority of users will want the Admin ;)

Lucee server will have local and remote providers.  The local provider will automatically give access to core extensions that ship by default.  Remote providers can give automated access to additional extensions, including third-party or bleeding edge versions of extensions. And we hope to provide options for folks to predefine their own custom local extensions for custom builds.

Performance and compatibility are critical things for Lucee; certainly we have no intention of jeopardising this with extensions. Indeed the hope is that extensions will vastly improve start up times for the server as a whole.

A lot of work is going on in this area at the moment.  When the dust settles we hope to give a clear view of exactly how the implementation is designed and open things up to discussion. For now we're trying to push the envelope a little and see what's possible.

GB

[Chris Blackwell]

The critical issue for us is that we can package our applications as a WAR file, including all required extensions at build time.
We can't have apps downloading stuff from remote providers at start up or needing run admin scripts post launch

Our ideal scenario would be extensions as Maven dependencies, so we'd just do something like

    <dependency>

      <groupId>org.lucee</groupId>

      <artifactId>lucee</artifactId>

      <version>5.0.0.x</version>

   </dependency>

    <dependency>

      <groupId>org.lucee.extension</groupId>

      <artifactId>hibernate-orm</artifactId>

      <version>1.0.0</version>

  </dependency>

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7cb0ea33-6945-4b5f-8762-a0b0c84ceb0e%40googlegroups.com.

[Nando Breiter]

In fact - and I think this is a key point - it seems one of Rory's main concerns: "that the extensions will not be maintained with the normal release cycle" is actually an argument in favor of this modular approach. Now - if there are issues that need to be addressed in the ORM extension, they can be done separately and/or on a different stream than that of the Lucee core. Specific ORM issues could now be addressed without waiting for more core point releases. If new ORM versions want to be used that require updated jars (for instance) then that could be done right away rather than waiting for major releases (the only time I believe core jars are allowed to be updated is between majors, right?)

This is an excellent point. One of the things I've noted about the ORM integration, whether in ACF or Railo, is that it has always lagged many years behind the current Hibernate release. I too use Hibernate in one of our applications, currently still on ACF primarily because of the uncertain status of ORM in Lucee, but I have to say that the ACF implementation seems perhaps more buggy to me, with the code I've implemented, than the Lucee implementation. 

Going forward, either I'll rip it all out and replace it with something else more reliable, or use the ORM extension available with Lucee 5. In any case, pulling ORM out into an extension allows it to be updated independently, and I think that's a very good thing. Who maintains it is a separate issue, but since it is an important feature of the language, we might expect someone would sponsor updates, as has already been offered in this thread, I think.

[Rory Laitila]

As Geoff says, insofar as this approach is an architectural OSGi based 'extension', such an approach is an implementation detail and not a concern at the level I'm speaking of. I'm speaking where traditionally 'extensions' in the Railo sense from the remote providers, were not in sync with core releases. They were essentially treated as third party add-ons, with separate development cycles, and would often become outdated and broken. This would not be a valid concern for me to raise, except for the fact, that here we are with a beta that is un-testable for most of my applications because the ORM 'extension' is unavailable due to it being broken. (Yes, all of this is besides the point, in that whether it is an extension or not, the ORM could still be broken and hold up the beta). So it comes down to it, what is considered 'core', whether or not it is an extension from an implementation perspective. Based on the historical quality of the extensions via the providers, I don't think my fear is unreasonable, but I can be corrected if I am wrong in the intention of the core development team.

As to the ability of extensions to be switched out and or improved at a faster pace than core as Andy mentions, that is not an issue or at question for me. The issue is extensions not keeping pace and falling behind.

[Michael Offner]

Yes, the extension is ready, we only wait for the release of the next beta version of Lucee 5, what is coming next week, because we limit that extension to this and newer versions.

FYI we will also bundle the Extension with the local extension provider so you have always access to the extension, even you have no access to the Internet.

Micha

Am Mittwoch, 10. Juni 2015 schrieb Tony Junkes :

Any updates as to when we might be able to try out the orm extension again?

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/b3270280-1905-46ee-b9d8-995ad22e3e3c%40googlegroups.com.

[Tony Junkes]

Awesome. Thanks so much, Micha!

[Michael Offner]

I can understand your concerns and we take that very serious believe me. With Lucee we completely changed how extensions work. The most important thing is we removed the support for user interaction in the install process what limits the functionality but allows us to install/load extensions without the need of user interaction. We already support to install extensions in 3 ways:

- in the admin

- by dropping in the file system

- by defining in the extension as part of Start script (system.properties)

And we will also support to do install in the cfml code, so you can for example trigger in the application.cfc

We see extensions in Lucee 5 totally different, we move stuff to extension that everyone needs like for example MySQL and mssql driver, but some of them are pre installed and some are available on the local update provider( see my previous post), we are on the way to remove the distinction between the core and extensions. 

Micha 

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/27b43514-6faf-4c55-8218-4331bb1141dc%40googlegroups.com.

[Nando Breiter]

This sounds excellent Micha! I'm impressed by the careful attention to detail and look forward to testing our code bases on Lucee 5!

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxN5MBq%2BEkc5HyV5Oqntw%3DgxMXgt6ym1apphtvSO8LhWg%40mail.gmail.com.