Fork me on GitHub
#datomic
<
2023-11-27
>
onetom05:11:01

Is it expected to have 0 downtime deployments on Datomic Cloud with 2 instances? We are regularly experiencing 1-2 minute downtimes during deployments.

Can08:11:43

Hello everyone, I want to ask one question,

(d/q
  '[:find ?e
    :where
    [?e :project/project-sd  [["Wed Nov 01 03:00:00 TRT 2023"] ["Fri Nov 03 03:00:00 TRT 2023"]]] 
;; My function is going to filter dates and return me that vector of vector data type which includes filtered dates. I want to get entity IDs for related dates. ←
    ]
  db)
;=> []
(d/q
  '[:find ?e
    :where
    [?e :project/project-sd  "Fri Nov 03 03:00:00 TRT 2023"]
    ]
  db)
;=> [[74766790688904]]
(d/q
  '[:find ?e
    :where
    [?e :project/project-sd  "Wed Nov 01 03:00:00 TRT 2023"]
    ]
  db)
;=> [[74766790688902]]

;My expected result: [[74766790688904] [74766790688902]] 
I have a working db and the given parameters are correct they are working single by single without a problem. How can I add multiple data to my query? If possible anyone have a working date filter function that I can take a look an get idea about the best way to do that? (I wrote one working filter function but comparison would be nice)

Linus Ericsson13:11:45

I don't understand what you want to get in your first query. ?pex and ?pe is not related in any way in this query so I think you try to solve many things in query, which is not needed in datomic, you can query the exact same consistent database many times for different data and then put it all together later. Which is also how you should solve the problem in this case.

Can13:11:39

there was a function row it gets ?psd as param and returns filtered date vector. [["Wed Nov 01 03:00:00 TRT 2023"] ["Fri Nov 03 03:00:00 TRT 2023"]] how can I use multiple params at the same to get ;My expected result: [[74766790688904] [74766790688902]]

Linus Ericsson13:11:42

Is the entity 74766790688904 (the first one in the vector above) and entity with a date string "Wed Nov 01 03:00:00 TRT 2023" as one its attributes? Then probably the function should return the eid directly. There can be potentially many strings with "Wed Nov 01 03:00:00 TRT 2023" as value, so you cannot be really sure which entity that was referred afterwards, right? As a side note, the serialization form of the date is somewhat redundant - I would use an ISO date format, but that's somewhat a matter of taste, of course.

Can14:11:19

I will replace it with (probably) epoch day πŸ™‚ I just wondering how to give multi params at the same time and get result.

Linus Ericsson10:11:40

As I said above I think you don't need to make the function call inside the query. Note that inside a query you cannot really work with sub-sets. Such things should be made in a different query. In SQL it is common to a lot of things in one query because you want ensure consistency, but Datomic works differently. It is a very common antipattern in Datomic to try to do too many different things in a single query. But check out https://docs.datomic.com/pro/query/query.html#expression-clauses for function call references. To specify sets in a query, there is a collection syntax, which can be used in :find and in the :in clause [?a …]

terjesb11:11:20

Does this work?

(d/q
  '[:find ?e
    :in $ [?psd ...]
    :where
    [?e :project/project-sd ?psd]]
  db ["Wed Nov 01 03:00:00 TRT 2023" "Fri Nov 03 03:00:00 TRT 2023"])

Can12:11:37

One more question, which is the best way to store Date in Datomic? 1- Epoch timestamp to store it in an long attribute. 2- iso8601 #inst to store in an instant attribute. 3- Any other ways that you can advise and which is best in your opinion and why?

Linus Ericsson12:11:06

This is a great question! What does the Date mean in your domain? Is it tied to a specific time zone? Is that implicit or explicit? You should consider to use epochday (number of days since 1 jan 1970) instead of a timestamp (this might be what you meant). This is convenient in that it has only one value for each date. Personally I think think using inst or other date+timestamps without a specified timezone is quite confusing (requires discipline) and a potential problem waiting to happen since it can be time-zone and summer/winter time-dependent and suddenly be misinterpreted. Also with a timezone you will use some convention on the date like "2023-11-27T00:00:00" means today 27th november. What does the timestamp at 1AM the same date mean? Is it a timezone error? Or a summer/winter time error? Or something else. Timezones and especially the changes of timezones is also somewhat scary when new locales are deployed (usually tied to the JVM version - of all things - IMO this is scary!). Another way to model dates could be model time periods as explicit entities in the database, indexed by epochday and or iso-date, which gives the possibility to add metadata and other things to a certain date entity (like this date is a bank holiday in country X), but has the drawbacks that new entities needs to be created for new dates, and the modelling certainly is untractable for shorter periods than days (hours, minutes, seconds...). Also these entities should not be allowed to be changed, which maybe would imply they should be modelled as primitives (epochday as long) for each attribute that uses it...

Linus Ericsson12:11:38

If I would to this modelling today, and would not have to model timezone etc, I would probably use epochday stored as a long as an attribute (the same attribute everywhere it was used to avoid confusion). I would add bank holidays as separate entities where the particular date is also stored as an epochday, and model which country the bank holidays was applicable. Then I would create some index of all the bankholidays in the running application (I'm in on-pred land here) Recurring things like weekends I would add to some functional logic. There is no use in storing every epoch day or every sunday to the end of the systems lifetime in the database. But it would be a good idea to jot down which time logic was used for a particular operation/running instance was in use for a particular operation (since locales etc can change, both in my own application and in the real world outside of my application).

πŸ™Œ 1
Can12:11:02

Thank you for the detailed explanation that is very precious, I wanted to use #inst is08601 but I wasn't sure about it. That's why I asked that. My parameters are stability against errors(in my opinion the date/time errors are very difficult to handle, problems grows like a snowball :D), easy of sorting, easy of filtering dates, and easy to use. So we can say +1 epochday then πŸ™‚ Any other opinions?

favila13:11:58

As a long which reads as ymd

πŸ‘ 3
favila13:11:46

Eg 20231127 is today

Can13:11:36

here is a converter, I found it very usefully πŸ™‚

Linus Ericsson13:11:03

EpochDay is availiable on the java.time.LocalDate. There are functionality for almost any conversion in the java.time.* library

cch113:11:17

I serialize java.time.LocalDate to EDN using https://github.com/henryw374/time-literals. Values are human readable and naturally sortable.

souenzzo09:11:28

I like always use ISO8601 standards, saved as string. Then you can use java.time to parse it.

indy20:11:24

I would go with epoch millis long, formatting time is a presentation layer thing. Passing long epochs everywhere while not caring about timezones and not parsing and formatting all over the place is the way to go. Only format at the boundaries, like in the front end ui.