Is ORM available in Lucee 5 Beta at the moment?

dev google-group-archive
#1

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?

#2

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…

MichaOn Mon, Apr 20, 2015 at 5:03 AM, Tony Junkes <@Tony_Junkes> wrote:

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?

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/162a60cb-ef24-4384-b02d-b25048f60c12%40googlegroups.com
https://groups.google.com/d/msgid/lucee/162a60cb-ef24-4384-b02d-b25048f60c12%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

#3

Thanks, Micha.

#4

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

#5

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…
AndyOn Thursday, June 11, 2015 at 3:27:11 PM UTC-7, Carl Von Stetten wrote:

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.

On 6/11/2015 2:15 PM, Samuel W. Knowlton wrote:

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.

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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

#6

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.On Thursday, June 11, 2015 at 10:04:36 AM UTC-7, Rory Laitila wrote:

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.

On Wednesday, June 10, 2015 at 2:36:19 PM UTC-4, Tony Junkes wrote:

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

#7

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.

#8

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.

#9

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

#10

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.On Wednesday, June 10, 2015 at 2:36:19 PM UTC-4, Tony Junkes wrote:

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

#11

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.On 6/11/2015 2:15 PM, Samuel W. Knowlton wrote:

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.

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+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

#12

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.On June 11, 2015 at 2:22:05 PM, ADK (@ADK) wrote:

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.

On Thursday, June 11, 2015 at 10:04:36 AM UTC-7, Rory Laitila wrote:
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.

On Wednesday, June 10, 2015 at 2:36:19 PM UTC-4, Tony Junkes wrote:
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f26a15c7-5712-4f90-b1dd-9d4878dfbb18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#13

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.On Thursday, June 11, 2015 at 2:45:42 PM UTC-4, Jon Clausen wrote:

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.

On June 11, 2015 at 2:22:05 PM, ADK (and...@leftbower.com <javascript:>) wrote:

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.

On Thursday, June 11, 2015 at 10:04:36 AM UTC-7, Rory Laitila wrote:

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.

On Wednesday, June 10, 2015 at 2:36:19 PM UTC-4, Tony Junkes wrote:

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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f26a15c7-5712-4f90-b1dd-9d4878dfbb18%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f26a15c7-5712-4f90-b1dd-9d4878dfbb18%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

#14

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.On Friday, June 12, 2015 at 5:05:14 AM UTC-4, Nando Breiter wrote:

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.

#15

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.

#16

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 :wink:

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

#17

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! :-)On Thursday, June 11, 2015 at 5:00:06 PM UTC-7, Samuel W. Knowlton wrote:

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.

On Thu, Jun 11, 2015 at 6:45 PM, ADK <and...@leftbower.com <javascript:>> wrote:

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

On Thursday, June 11, 2015 at 3:27:11 PM UTC-7, Carl Von Stetten wrote:

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.

On 6/11/2015 2:15 PM, Samuel W. Knowlton wrote:

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.

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
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/71bac58a-a4af-42c1-bfc7-1a6e0082faac%40googlegroups.com
https://groups.google.com/d/msgid/lucee/71bac58a-a4af-42c1-bfc7-1a6e0082faac%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

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

#18

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.On Thu, Jun 11, 2015 at 6:45 PM, ADK <@ADK> wrote:

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

On Thursday, June 11, 2015 at 3:27:11 PM UTC-7, Carl Von Stetten wrote:

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.

On 6/11/2015 2:15 PM, Samuel W. Knowlton wrote:

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.

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
https://groups.google.com/d/msgid/lucee/d34e0556-af2e-476c-9e0d-e53be372de5a%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/71bac58a-a4af-42c1-bfc7-1a6e0082faac%40googlegroups.com
https://groups.google.com/d/msgid/lucee/71bac58a-a4af-42c1-bfc7-1a6e0082faac%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

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

#19

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.

MichaAm Donnerstag, 11. Juni 2015 schrieb 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.

On Wednesday, June 10, 2015 at 2:36:19 PM UTC-4, Tony Junkes wrote:

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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/27b43514-6faf-4c55-8218-4331bb1141dc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/27b43514-6faf-4c55-8218-4331bb1141dc%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

#20

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.

MichaAm 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+unsubscribe@googlegroups.com <javascript:;>.
To post to this group, send email to lucee@googlegroups.com <javascript:;>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/b3270280-1905-46ee-b9d8-995ad22e3e3c%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.