http://coldfusion.com logo
Join Slack
Powered by
the property definition is string / sqltype varcha...
# box-products
s
the property definition is string / sqltype varchar, so no CFML metadata indicating it's a boolean
w
looking at the definition of a boolean here. Using the isBoolean function will not help you, but how would you detect something is not a boolean here? If that’s clear there would be ways to apply your own logic without changing the code in mementifier itself, or by creating some setting for it. At least it is not in the mementifier settings, but I guess you already figured that out.
s
Because I've told the component in the property definition that it's a string, not a boolean
so if it finds "yes" it should say "yes" not 
true
w
Ok, so reading the property definition (and obeying the datatype there) would be enough? It shouldn’t be too hard to modify. Should be even better if it was an option in mementifier
I can imagine why they don’t do that by default though. Metadata calls can be slow (but can be cached, so I guess no real problem)
I think qb and quick have the same kind of ‘logic’. Detecting datatypes instead of just realizing the DEFAULT is always a string, unless you specify something else in your property definitions. So actually your logic would be
Copy code
else if ( !isNumeric( thisValue ) && isBoolean( thisValue )  && NOT_A_STRING_PROPERTY   )
Not sure if that would break code in other places.
s
yeah, it would probably be considered a breaking change. I know Quick already does metadata introspection and stores stuff in Wirebox, mementifier could look there I guess
w
I was also thinking about datatype detection. In cf2016 this is just a string
Copy code
myVar = true;
In more recent ACF and lucee 
getMetadata(myVar).getName()
can distinguish between strings and booleans. Depending on your version property definitions might be better. But in that case you ALWAYS have to make sure your booleans are defined as such in your property definitions. (or make this behaviour a switch in the module settings)
s
Yeah, I can't really complain about incorrect type handling if I haven't correctly typed my properties
w
Maybe we should just create some pull so all date detection just obeys the property definitions. That would also solve these date problems, so my dutch cellphone numbers do not change to dates automagically. So call it propertyDataDetection and make it a switch? @lmajano Does that make sense?
l
Sometimes there are no property definitions. So you can't follow that because it could be mementifier getting state from a non orm object
You can't assume it's orm
And yes. The is Boolean is a problem because of the yes and no.
Possible solutions could be being explicit about types on the included
So that the marshaling is not assuming
That's the only way. Because inferring only takes you so far
s
doesn't have to be an ORM object. any component can have 
type
l
But some don't. And reading metadata is slow
s
But wirebox is already doing a bunch of mementifier stuff on these objects at app start. Quick has already introspected the metadata. we have all the pieces to the puzzle. if people without components with metadata want to solve this a different way there's no reason they can't, but right now it's assuming anything that COULD be a Boolean IS a boolean, which means I have to go tell every single string property on every single component that might == "Yes" or "No" to have special behavior. that's actually easy for us right now, but doesn't seem like a super great solution in the long run
l
But it's not only yes and no. 1 and 0 are also truthy values
Not saying no. Just probing for the solutions that could encompass most scenarios
In the most performant way
s
sure, but you've solved for that already:
Copy code
else if ( !isNumeric( thisValue ) && isBoolean( thisValue ) ) {
so we don't get funky behavior with numeric fields
(and because most anything expecting a boolean can handle getting 1 or 0 more easily than anything expecting a string "Yes" or "No' can get 
true
or 
false
)
l
What would be your preferred way
s
I think you could carve out a way of dealing with this for Quick/CBORM entities because mementifier is already 'doing stuff' when they're wired up and the metadata has already been cached in Wirebox. I don't think we need a galactic solution here, or at least, if so, don't let the perfect be the enemy of the good. If Mementifier has easy access to metadata, use that; if it doesn't, guess, or wait for somebody to propose a better solution
l
It's not about perfect it's about speed
Once you start introspection h metatadat you get into more holes due to possible recursions
You can't just do one level
What do you introspect. Only Boolean's
w
Is cached metadata slow?
l
You still need to go through it
Recursively
Basically I am trying to evaluate all ahora
Angles
s
you introspect whatever you need to to solve the problem you're having. this particular problem is pretty specific to booleans
w
I was wondering, can't you just add an extra check if isboolean() is true? Check datatype there?
s
if you're mementifying 100 objects, you don't want to check 100 times though, you want to check once and keep a list behind the bar: 'do not serve 
true
or 
false
to these customers'
l
exactly, so then now we are into caching things
another layer
s
seems like mementifier would benefit from a cache layer in general though
w
Will eork on acf2018 and lucee
What i suggest will only add an extr chech to something which can be a boolean
l
hmm seems quick doesn’t use the 
type
attribute for properties
w
Not required no
s
we always use it, though, except occasionally for dates where it complains about 
""
values
l
I would need a 
type
to determine if it’s a 
string
or 
boolean
to have consistency with properties
the default is 
any
which I am guessing you are using @sknowlton
in this property
s
property name="answer"         type="string" sqltype='varchar';
there's our property def
w
Isn't the default string?
l
yep
s
we rarely use 
any
l
ok
If we add this, I would like to add two ways to do it
an explicit and an implicit way
implicit means focusing on the property 
type
explicit would be on the 
includes
list
and caching is more complicated, because you can’t cache locally as you can be in a transient,
you have to reach out of the object
s
yep, which is what Quick does I think
same reason
l
I say, create a ticket and let’s put our findings there.
I just want to make sure there are no other use cases for other casting scenarios apart from boolean
w
Is there some autodetection of dates
In mementifier?
l
yes, but based on regex
using 
isDate()
was 10000 times slower
Copy code
// Match timestamps + date/time objects
			else if (
				isSimpleValue( thisValue )
				&&
				(
					reFind( "^\{ts ([^\}])*\}", thisValue ) // Lucee date format
					||
					reFind( "^\d{4}-\d{2}-\d{2}", thisValue ) // ACF date format begins with YYYY-MM-DD
				)
			) {
I had to base it off date time stamps
but this can be another edge case
w
isdate is ruining my phonenumbers
l
isDate()
is broken in my opinion
when I did stress tests optimizing mementifier
that function was terrible
on performance
w
I agree but it is used in quick and qb. I have toexplicitly cast stuff to srings if my string contains a phone number. Wrong defaulthandling in my opinion
l
I would stay away from using 
isDate()
w
Don't tell me 🤣
l
lol
Where is that in use
it’s best to use the new JDK 
java.time
package
w
I think qb does some automatic queryparam detection
l
good article for you
w
I will read it and see if we can improve this
l
This one too
very good articles
I know you like your reading 🙂
This is the issue I was getting in ACF and Lucee
Copy code
Thread safety – The Date and Calendar classes are not thread safe, leaving developers to deal with the headache of hard-to-debug concurrency issues and to write additional code to handle thread safety. On the contrary, the new Date and Time APIs introduced in Java 8 are immutable and thread safe, thus taking that concurrency headache away from developers.
I use them in the ColdBOx task Manager
but I think qb/quick could probably benefit from them too
I did not know it 🙂
as well, I mostly deal with cborm
What do you guys think of also making the 
includes
more specific
maybe in the future support more metadata about mementification
for example
instead of just saying 
answer
do
Copy code
{ property : "answer", castTo : "boolean" }
just brainstorming
w
I mostly use manual includes, so I think that would be interesting. But in ORM and quick I guess you can do a lot of automatic includes. Maybe just don’t use auto includes if you are expecting problems on some fields.
s
that would be cool
3 Views
Open in Slack
PreviousNext
Powered by